Diego Foliene

Conferindo por volta das 21h00, já não constam mais relatos de problemas no DownDetector, indicando a normalização da situação.

Olá pessoal! No dia 21/01/2025 foi publicado comunicado no Portal SPED informando que se encontra disponível para download a versão 6.0.0 do PGE da EFD contribuições. A nova versão engloba as alterações previstas na Nota Técnica 009_2024. É recomendado realizar o backup preventivo das escriturações presentes no banco de dados e também a instalação em pasta distinta da atual a fim de evitar conflitos com versões anteriores. Contribuintes que já fizeram a importação na versão 5.1.1 deverão exportar e importar, editar, validar, assinar e transmitir novamente na versão 6.0.0. Leia o comunicado na íntegra AQUI.

Olá pessoal! Foi publicado no dia 21/01/2025 comunicado no portal SPED informando sobre a versão 11.0.1 do programa da ECF utilizado para transmitir arquivos do ano-calendário 2024 e situações especiais 2025 (leiaute 11). A nova versão traz as seguintes atualizações: Fonte: http://sped.rfb.gov.br/pagina/show/7649

Boa tarde @engloba_sistemas. A mensagem da a entender que o certificado não foi configurado corretamente na Lib. Por favor, procure pelo arquivo ACBrLib.ini que centraliza suas configurações e veja como está seção DFe no mesmo. Este é um exemplo de seção configurada para A1 com OpenSSL. [DFe] SSLCryptLib=1 SSLHttpLib=3 SSLXmlSignLib=4 UF=SP TimeZone.Modo=0 TimeZone.Str= URLPFX= ArquivoPFX=C:\Users\Diego\Documents\Cert\MeuCertificado.pfx DadosPFX= Senha=SenhaDoMeuCertificadoCriptografadapelaLib NumeroSerie= VerificarValidade=1

Olá pessoal! No dia 21/01/2025, por volta das 08h09, começamos a receber relatos no canal #sefaz em nossa comunidade do Discord de membros com problemas para emissão de NF-e junto a Sefaz de São Paulo. Todos os relatos tem em comum a Sefaz estar devolvendo a rejeição: Mesmo a informação estando correta de acordo com consultas disponíveis como o Sintegra. Conferindo no DownDetector, é possível observar que o volume de relatos de problema aumentou exponencialmente durante o mesmo período: Não á até o momento da publicação deste tópico aviso sobre contingência publicado no Portal da Nota Fiscal Eletrônica.

Bom dia @giovani deitos. Revise seus arquivos schemas e seu processo para se certificar de que esteja utilizando arquivos de schema atualizados(Pegue eles do SVN em ..\trunk2\Exemplos\ACBrDFe\Schemas\NFe) e que seu software esteja buscando eles no local adequado. O leiaute da NF-e foi atualizado, aumentando o tamanho do campo cAut para 128 caracteres conforme Nota Técnica 2023/004 justamente para permitir informar o end2endId no campo. Essa alteração já foi feita no ACBr e portanto, se você está recebendo erro de validação de schema, isso significa que seus fontes e schemas estão desatualizados. O xCampo está aparecendo. Ele é um atributo do campo xTexto, veja em seu XML: <obsCont xCampo="idPix"> <xTexto>E187Ce4512fadCFacd6323974Bd4DfDb</xTexto> </obsCont>

Tópico movido para a área do ACBr Pro, para que o SLA de respostas seja considerado

Olá pessoal! O membro de nossa comunidade @Samuel Alles Remlinger compartilhou conosco essa resposta que obteve após abrir chamado junto a Serpro sobre o problema:

Siga as orientações do tópico abaixo para utilizar as soluções do ACBr em contingência durante este período:

Por favor, consegue realizar um teste no ambiente de produção com uma nota no valor baixo? A estrutura do arquivo está correta. Apesar de informações como o tópico abaixo indicarem que o estado do MT adota o e-Conf, tudo indica que eles não o fizerem de fato, que é um problema interno. Isso ou este pode ser um comportamento do ambiente de homologação. Vale abrir um Fale Conosco junto a Sefaz para questionamento.

Boa tarde! No que diz respeito ao retorno para NF-e, é possível que o ambiente de homologação da UF esteja passando por instabilidade. Realizando testes de consulta pela chave de acesso em meu ambiente estou recebendo o seguinte retorno: <?xml version="1.0" encoding="utf-8" ?> <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> <soapenv:Body> <nfeResultMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NFeConsultaProtocolo4"> <retConsSitNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"> <tpAmb>2</tpAmb> <verAplic>MT_A2RL-4.00</verAplic> <cStat>999</cStat> <xMotivo>Rejeicao: Erro nao catalogado</xMotivo> <cUF>51</cUF> <dhRecbto>2025-01-17T13:43:37-04:00</dhRecbto> <chNFe>$entidade.chNFe</chNFe> </retConsSitNFe> </nfeResultMsg> </soapenv:Body> </soapenv:Envelope> Depois de insistir recebi o retorno de nota autorizada. Quanto ao retorno do envio para NFC-e, a mensagem me parece "desatualizada", visto que não existe o cUF na estrutura do arquivo e sim o cOrgao. Na NT também consta a seguinte orientação para o cOrgao: O caso de MT entraria na parte "informar o Código da UF do Emitente, para as SEFAZ com ambiente de autorização próprio.", no entanto, como você recebeu esta rejeição, se possível, faça um teste enviando com o valor 92.

Boa tarde! A URL da consulta termina em cadconsultacadastro2.asmx Conferindo no arquivo ACBrNFeServicos.ini existe a cadconsultacadastro4.asmx Por favor, confira se definiu corretamente a configuração VersaoDF.

Bom dia! A Lib vai gerar para você o arquivo XML do RPS. Você envio o XML do RPS para o web service do provedor, ele processa o arquivo e se estiver tudo certo, o web service quem vai gerar e devolver o XML da NFS-e para você. No entanto, o provedor que atende ao município de Varzea Grande/MT é o Abaco em sua versão 1.00; Esta versão segue o leiaute da ABRASF de mesma versão e a inscrição estadual do tomador de serviços não faz parte do leiaute. Vide arquivo de schemas.

Bom dia! Por favor, pode fornecer detalhes como o a UF configurada no componente e o CNPJ consultado para que possamos realizar um teste em nosso ambiente?

Entendendo o problema. O Manifesto Eletrônico de Documentos Fiscais (MDF-e), conforme seu leiaute, permite que sejam referenciados documentos originários. Estes documentos podem ser CT-es, NF-es ou outros MDF-es. Esta é a regra de validação corresponde a esta rejeição de acordo com o MOC Anexo I - Leiaute e as Regras de Validação: Conforme é possível observar, se você está recebendo está rejeição significa que essas informações não foram encontradas no arquivo XML que foi enviado ao web service. Como resolver? Se você utiliza o componente nativo para Delphi/Lazarus, precisa referenciar o documento conforme exemplo: var LManifesto: TManifesto; LInfMunDescarga: TinfMunDescargaCollectionItem; LInfCTe: TinfCTeCollectionItem; LInfCT: TinfCTCollectionItem; LinfNFe: TinfNFeCollectionItem; LInfMDFeTransp: TinfMDFeTranspCollectionItem; LInfUnidTransp: TinfUnidTranspCollectionItem; Lperi: TPeriCollectionItem; begin LManifesto := ACBrMDFe1.Manifestos.Add; LInfMunDescarga := LManifesto.MDFe.infDoc.infMunDescarga.New; //=============>CT-e<============================= LInfCTe := LInfMunDescarga.infCTe.New; LInfCTe.chCTe := ''; LInfCTe.SegCodBarra := ''; LInfCTe.indReentrega := ''; LInfUnidTransp := LInfCTe.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; Lperi := LInfCTe.peri.New; Lperi.nONU := ''; lperi.xNomeAE := ''; Lperi.xClaRisco := ''; Lperi.grEmb := ''; Lperi.qTotProd := ''; Lperi.qVolTipo := ''; LinfCTe.infEntregaParcial.qtdTotal := 0; LinfCTe.infEntregaParcial.qtdParcial := 0; with LinfCTe.infNFePrestParcial.New do chNFe := ''; //=============>CT<============================= LinfCT := LInfMunDescarga.infCT.New; LInfCT.nCT := ''; LInfCT.serie := 0; LinfCT.subser := 0; LinfCT.dEmi := Now; LinfCT.vCarga := 0; LInfUnidTransp := LInfCT.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; //=============>NF-e<============================= LinfNFe := LInfMunDescarga.infNFe.New; LinfNFe.chNFe := ''; LinfNFe.SegCodBarra := ''; LinfNFe.indReentrega := ''; LInfUnidTransp := LInfNFe.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; Lperi := LInfNFe.peri.New; Lperi.nONU := ''; lperi.xNomeAE := ''; Lperi.xClaRisco := ''; Lperi.grEmb := ''; Lperi.qTotProd := ''; Lperi.qVolTipo := ''; //=============>MDF-e<============================= LInfMDFeTransp := LInfMunDescarga.infMDFeTransp.New; LInfMDFeTransp.chMDFe := ''; LInfMDFeTransp.indReentrega := ''; LInfUnidTransp := LInfMDFeTransp.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; Lperi := LInfMDFeTransp.peri.New; Lperi.nONU := ''; lperi.xNomeAE := ''; Lperi.xClaRisco := ''; Lperi.grEmb := ''; Lperi.qTotProd := ''; Lperi.qVolTipo := ''; Caso utilize ACBrMonitorPLUS ou ACBrLib: ; Utilize tags abaixo para Adicionar CTes Relacionados [infCTe001001] chCTe= SegCodBarra= indReentrega= [peri001001001] nONU= xNomeAE= xClaRisco= grEmb= qTotProd= qVolTipo= [infEntregaParcial001001] qtdTotal=0 qtdParcial=0 [infUnidTransp001001001] idUnidTransp= tpUnidTransp= qtdRat= [lacUnidTransp001001001001] nLacre= [infUnidCarga001001001001] idUnidCarga= tpUnidCarga qtdRat= [lacUnidCarga001001001001001] nLacre= ; Utilize tags abaixo para Adicionar NFes Relacionadas [infNFe001001] chNFe= SegCodBarra= indReentrega= [peri001001001] nONU= xNomeAE= xClaRisco= grEmb= qTotProd= qVolTipo= [infUnidTransp001001001] idUnidTransp= tpUnidTransp= qtdRat= [lacUnidTransp001001001001] nLacre= [infUnidCarga001001001001] idUnidCarga= tpUnidCarga qtdRat= [lacUnidCarga001001001001001] nLacre= ; Utilize tags abaixo para Adicionar MDFes Relacionados [infMDFeTransp001001] chMDFe= indReentrega= [peri001001001] nONU= xNomeAE= xClaRisco= grEmb= qTotProd= qVolTipo= [infUnidTransp001001001] idUnidTransp= tpUnidTransp= qtdRat= [lacUnidTransp001001001001] nLacre= [infUnidCarga001001001001] idUnidCarga= tpUnidCarga qtdRat= [lacUnidCarga001001001001001] nLacre= Eu preenchi estas informações, mas mesmo assim elas não foram geradas no meu XML. Para entender isso, primeiro precisamos observar as regras de validação das rejeições 638, 639 e 540: Veja que de acordo com o Tipo do Emitente (tpEmit) que foi preenchido no MDF-e, um determinado tipo de documento não pode ser referenciado. As soluções do ACBr já fazem estas tratativas internamente. Então se, por exemplo, você preencheu o valor 1 para o tpEmit, e preencheu as informações de uma NF-e referenciada, essas informações não serão adicionadas no XML. Você deve corrigir o tpEmit.

Erro: Uma chamada para a função PInvoke desbalanceou a pilha. Possível causa do problema: As bibliotecas ACBrLib além de versões Single Thread e Multi Thread também são compiladas considerando a convenção de chamada da linguagem que vai utiliza-lá. Está convenções de chamada são StdCall e Cdecl. Este erro ocorre quando você está utilizando uma ACBrLib com a convenção de chamada diferente das utilizadas pelas classes. Como resolver: Quando você faz o download da ACBrLib, você vai encontrar as convenções de chamada diferentes: Por padrão, os exemplos do C#, Java e VB6 fazem uso da convenção Cdecl: Certifique-se de que esteja utilizando a dll da convenção de chamada correta. Neste exemplo eu devo utilizar a Cdecl ou alterar na classe para que use StdCall como convenção de chamada para que possa usar a dll correspondente.

Erro: System.Exception: "" `Possível causa do problema: As bibliotecas ACBrLib são distribuídas em versões Single Thread e Multi Thread. Também são disponibilizados exemplos Single Thread e Multi Thread para consumir essas respectivas bibliotecas. Este erro pode acontecer quando você utiliza a versão Multi Thread da ACBrLib com o exemplo Single Thread. Como resolver: Os exemplos Single Thread e Multi Thread são identificados no nome. Single Thread Multi Thread Quando você faz o download da biblioteca ACBrLib, a mesma vem dentro da pasta dep conforme a estrutura: Se estiver utilizando o exemplo Single Thread certifique-se de ter distribuído a Lib Single Thread e caso esteja utilizando o exemplo Multi Thread, tenha certeza de estar usando a Lib Multi Thread. Possível causa do problema: Quando você executa a ACBrLib, ela automaticamente cria para você um arquivo ACBrLib.ini que centraliza todas as configurações da biblioteca. Este erro também pode ocorrer caso o arquivo ACBrLib.ini está com alguma configuração inválida. Como resolver: Será preciso realizar um pequeno processo para buscar entender qual é a seção e qual é a configuração da mesma que está com o valor inválido. Renomeie seu arquivo ACBrLib.ini que centraliza as configurações da biblioteca para que ele fique de backup. Pode chamar de ACBrLibBKP.ini por exemplo. Execute novamente a aplicação para que um novo arquivo ACBrLib.ini em branco seja criado. Substitua uma seção do arquivo em branco pela seção do arquivo backup, execute a aplicação, caso não dê erro, pare a execução, substitua uma nova seção e execute novamente. Execute o passo 3 gradativamente até que volte a ter o problema de inicialização. Assim, você pode descobrir qual é a seção do arquivo ACBrLib.ini que está com a informação inválida repita novamente o passo a passo agora alterando somente as informações desta seção até encontrar qual é a informação que tem o valor inválido. Como identificar por qual das duas possibilidades eu estou passando? O arquivo de Log gerado pela ACBrLib pode ajudar com esta questão. Este é o log no nível paranoico gerado pela Lib com a dll MT no exemplo ST: Este é o log no nível paranoico gerado pela Lib com uma informação inválida no arquivo ACBrLib.ini:

Boa tarde @juniorguillen. Foram enviados ao SVN ajustes visando corrigir ambas as questões relatadas. Para o problema com o método para despachar um pedido, foi adicionado uma classe deliveryTrackingInfo que vai gerar para você um JSON no body conforme documentação. (Foi adicionado exemplo de preenchimento das propriedades no programa exemplo).

Boa tarde! Conferindo aqui, o campo existe no impresso, no entanto, não encontrei nos fontes momento em que o mesmo seja alimentado. Criada a #TK-6493 para análise do caso e parecer por parte da equipe de consultores. Qualquer novidade será divulgada no tópico. EDIT: Conforme esclarecimentos, não há alteração ou correção a serem feitas nos fontes. Portanto a TK foi arquivada.

Bom dia! Estamos buscando mais informações a respeito. Reportamos assim que descobrirmos algo. Durante este meio tempo, por favor, pode realizar um teste com o PostMan para verificar se também devolve este mesmo erro?

Erro: Não foi possível carregar a biblioteca na pasta da aplicação ou caminho padrão. Possível causa do problema: Talvez um dos erros mais comuns de quem está tentando utilizar a ACBrLib pela primeira vez. Este erro ocorre porque a aplicação não conseguiu encontrar a dll ACBrLibNFe no local que esperava encontrar. Como resolver: Quando se trabalha com a ACBrLib, é necessário distribuir a mesma junto de sua aplicação para correta comunicação e uso. As classes do ACBr para os exemplos do C#, do Java, do VB6 por padrão buscam ela em um caminho seguindo a estrutura ..\ACBrLib\x86 ou ..\ACBrLib\x64 dependendo da arquitetura da aplicação. Então em nosso exemplo C# da NF-e eu devo adicionar as pastas e a dll na estrutura de forma que fique:

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Olá pessoal! Por volta das 08h56 do dia 14/01/2025 começamos a receber múltiplos relatos em nossa comunidade do Discord nos canais #acbrnfe, #sefaz e #pro-nfe de membros da comunidade com problemas com a manifestação do destinatário. Os relatos tem em comum: A não disponibilização dos resumos de notas recentes para o envio de eventos de manifestação, mesmo as notas estando presentes no portal nacional para consulta. A não disponibilização da nota completa após o envio de um evento de manifestação conclusivo. Quando falamos do processo de distribuição dessas notas durante o processo de manifestação do destinatário, é importante reforçar algumas coisas: O processo de sincronização entre os ambientes estaduais e nacionais pode acarretar em um intervalo entre a emissão da nota fiscal eletrônica e a disponibilização da mesma. O web service distribui as notas de até os últimos 90 dias, não trazendo notas emitidas com datas que ultrapassem este limite. Se o cliente deixar de utilizar o serviço por mais de 60 dias, a distribuição é interrompida, sendo necessária nova consulta para voltar a distribuir a partir do momento da mesma. O web service não distribui as notas de forma retroativa. Os documentos que serão recebidos podem variar de acordo com o papel que o CNPJ que está consultando desempenhe no processo de emissão da NF-e(por exemplo, um CNPJ que desempenhe um papel de emissor, não vai receber as notas que emitiu). Possíveis causas: Se certificar de que o cliente faz uso da consulta de Distribuição DFe regularmente para que a mesma não deixe de distribuir os NSUs. Se certificar de que não está havendo consulta paralela para que outro software ou ferramenta de captura esteja recebendo os XMLs que você esperava receber. Se certificar de que o CNPJ que está realizando a consulta de fato recebe os XMLs que espera receber. Se você conferiu todas essas questões, tudo está correto e mesmo assim ainda está tendo problemas, é importante que abra um Fale Conosco junto ao ambiente nacional que é responsável pelo processo de Manifestação relatando o problema. Você pode fazer isso através do link https://www.serpro.gov.br/menu/suporte/css, selecionando a opção "SPED - NFe e CTe" na lista. Quanto mais pessoas reportarem, mais cedo o pessoal da Receita entende que possa existir um problema. Não há comunicado oficial relacionado no Portal da Nota Fiscal até a publicação deste tópico.

Olá pessoal! Foi publicado no dia 14/01/2025 o Informe Técnico 2023/003 v1.05 que divulga atualização da Tabela de Combustíveis Sujeitos a Tributação Monofásica, com implantação prevista tanto em homologação quanto em produção no dia 01/02/2025.