Painel de líderes

Olá comunidade ACBr, Este tópico tem o objetivo de auxiliar quem estiver com problemas nas integrações com o eFrete para geração do CIOT e demais métodos da integradora. Foram mapeados erros e documentadas dicas para solução. 1. Autenticação 1.1. Geral 1.1.1. Integrador não cadastrado * Integrador.Nao.Cadastrado * O HASH fornecido pelo eFrete não foi preenchido 1.1.2. Integrador de software não homologado para esta solicitação. * Preenchido HASH inválido 1.2. Método de Login 1.2.1. O retorno do método não gera token, mas não gera rejeição acusando o problema * Verificar se está preenchendo o Hash válido, mas usuário e/ou senha inválidos * Se for configurado certificado digital, este método não deve ser utizado, para geração de token deixar os dados de certificado sem preenchimento 1.2.2. Erro adicionando operação de transporte: Usuário não logado * Usuario.Nao.Logado * Consumo de qualquer método com um token antigo/encerrado 2. Adicionar Operação 2.1. Operação de transporte já cadastrada * IdCliente.Existente * Já existe um CIOT cadastrado, necessário encerrar a operação existente 2.2. '' não é um valor válido para TipoIndicadorPagamentoEnum * Nos dados de pagamentos, preencher a chave IndicadorPagamento com AVista ou APrazo 2.3. Código NCM deve se r entre 1 e 9999 * CodigoNCM.Fora.Da.Faixa * Preencher a chave CodigoNCMNaturezaCarga com o devido valor entre 1 e 9999 * Verificados locais informando que são os 4 primeiros dígitos do NCM do produto de maior valor da carga 2.4. Foi identificado pelo sistema diferentes valores para o campo TipoPagamento, verifique se foi informado o mesmo valor para o campo TipoPagamento na raiz da chamada, na raiz de Viagem e de Pagamento. * Caso não enviado algum campo o sistema assumirá a primeira posição dos itens que também pode não coincidir com o valor desejado. * Regra.Negocio * Preencher no cadastro do CIOT, Viagem e Pagamento, o mesmo valor nas chaves TipoPagamento > 1-TransferenciaBancaria, 2-eFRETE, 3-Parceiro, 4-Outros, 5-DepositoAgendado * Exemplo: TipoPagamento=1 2.5. Data de início da viagem deve ser maior ou igual à data atual * Data.Inicio.Viagem.Anterior.Ao.Dia.Atual * Preencher o valor correto na tag DataInicioViagem 2.6. Código do tipo de carga inválido. Deve ser maior que 0 e menor ou igual a 12 * Codigo.Tipo.Carga.Fora.Da.Faixa * Preencher a chave CodigoTipoCarga com valor entre 1 e 12: 0-tpNaoAplicavel, 1-tpGranelsolido, 2-tpGranelLiquido, 3-tpFrigorificada, 4-tpConteinerizada, 5-tpCargaGeral, 6-tpNeogranel, 7-tpPerigosaGranelSolido, 8-tpPerigosaGranelLiquido, 9-tpPerigosaCargaFrigorificada, 10-tpPerigosaConteinerizada, 11-tpPerigosaCargaGeral, 12-tpGranelPressurizada * Exemplo: CodigoTipoCarga=5 2.7. Erro validando Destinatário: Documento inválido(a) * Regra.Negocio * O mesmo ocorre para a seção Contratante * Preencher a chave CpfOuCnpj da respectiva seção com um documento válido 2.8. Erro validando Destinatário: Nome é obrigatório * Regra.Negocio * O mesmo ocorre para a seção Contratante * Preencher a chave NomeOuRazaoSocial da respectiva seção 2.9. Destinatario. Erro validando Destinatário: Rua não pode ser em branco - O mesmo para os demais campos de endereço * Regra.Negocio * O mesmo ocorre para a seção Contratante * Preencher as chaves de endereço na respectiva seção Bairro= Rua= Numero= Complemento= CEP= CodigoMunicipio= 2.10. Algum dos envolvidos na operação de transporte deve ser informado como o responsável pelo pagamento * Deve.Haver.Responsavel.Pelo.Pagamento * Preencher a chave ResponsavelPeloPagamento=1 em uma das seções: Contratante, SubContratante, Consignatario, TomadorServico, Remetente, ProprietarioCarga 2.11. Os dados bancários não foram informados, não são de uma conta válida ou estão em formato errado. [Formato Agencia: Numero-Digito (Se houver). Conta: Numero-Digito] * Conta.Bancaria.Invalida * Preencher as chaves a seguir nas seções Viagem e/ou Pagamento InstituicaoBancaria= Agencia= Conta= 2.12. Motorista não encontrado * Motorista.Nao.Encontrado * Preencher as chaves da seção Motorista, com valores válidos CpfOuCnpj= CNH= 2.13. Não foi encontrado nenhum transportador com CPF/CNPJ XXXXXXXXXXXXXXX e RNTRC XXXXXXXXX * Preencher com valores válidos as chaves a seguir da seção Contratado CpfOuCnpj= RNTRC= 2.14. Usuário não possui permissão na transportadora com CNPJ 04430502000103, ou permissão insuficiente * Usuario.Sem.Permissao.Na.Transportadora.Ou.Permissao.Insuficiente * Em HOMOLOGAÇÃO: Nos dados do CIOT, preencher as chaves a seguir com o CNPJ cadastrado na conta do portal dev MatrizCNPJ=XXXXXXXXXXXXXX FilialCNPJ=XXXXXXXXXXXXXX 2.14.1. Envio com token * As credenciais podem estar ativas logando com cpf ou e-mail, confirme as credenciais recebidas do suporte do e-frete * Mesmo gerando token válido, o usuário preenchido com cpf ou e-mail pode não ter permissão para emissão do CIOT * Validar o login com cpf ou e-mail e verificar se o token com uma das opções não cai na rejeição 2.15. O CNPJ do MatrizCNPJ deve ser igual do Contratado ou do Contratante * Matriz.Cnpj.Invalido * Preencher o mesmo CNPJ da chave MatrizCNPJ em CpfOuCnpj da seção Contratado ou Contratante 2.16. Veículo com placa: AAA1234 com RNTRC inválido * Veiculo.RNTRC.Invalido * Corrigir a chave Placa da seção Veículo 2.17. O valor do frete informado é menor do que o valor mínimo de frete estabelecido * Revisar as chaves de valores a seguir das seções Viagem e Pagamento * Viagem TotalOperacao= TotalViagem= TotalDeAdiantamento= TotalDeQuitacao= Combustivel= Pedagio= OutrosCreditos= Seguro= OutrosDebitos= * Pagamento Valor= 2.18. Operação de transporte já cadastrada * IdCliente.Existente * Mesmo IdOperacaoCliente já cadastrado em outro CIOT 3. Adicionar Viagem 3.1. Campo CepOrigem com o valor '' é inválido ou Campo CepDestino com o valor '' é inválido * Campo.Invalido * Preencher as chaves CepOrigem e CepDestino da seção Viagem 3.2. É obrigatório preencher os valores das viagens * Problema verificado em HOMOLOGAÇÃO, mas identificado o motivo * Viagem.Valores.Nulo * Revisar as chaves de valores a seguir da seção Viagem * Mesmo preenchendo todos os campos de valores, assim como feito na inclusão do CIOT, o problema persiste em HOMOLOGAÇÃO 4. Consultar Tipo de Carga * Este.Metodo.Foi.Desabilitado.Nao.Requerido.Emissa.oCiot * Método desabilitado pelo e-Frete 5. Erros em homologação que não acontecem em produção 5.1. Encerrar Operação 5.1.1. Erro 400 * Encerrar CIOT com DataInicioViagem futura * Erro ao enviar CIOT Código de erro: -10. Último retorno: Erro Interno: 0 * Erro HTTP: 400 * URL: https://dev.efrete.com.br/Services/PefServiceV2.asmx 5.2. Outros 5.2.1. A requisição não pode ser nula / Requisição inválida * Requisicao.Nao.Pode.Ser.Nula * Requisicao.Nula * Diversos métodos geram estas rejeições em Homologação, não foi identificado o motivo e não conseguimos suporte do efrete para identificação do problema * GravarAdicionarPagamentos, GravarAlterarDataLiberacaoPagamento, GravarCancelarPagamento, GravarRegistrarPagamentoQuitacao, GravarRegistrarQtdeMercadoriaDesembarque, GravarRetificarOperacao Contamos com a contribuição da comunidade: Caso encontrem a solução para algum dos erros acima ainda não identificados para atualizarmos este tópico e ajudar quem mais tiver problemas com essa integradora. Até mais!!!

Reforma Tributária na NF-e: ACBr aprimora a geração do grupo gPagAntecipado Quem emite NF-e sob as regras da Reforma Tributária e usa notas anteriores para abater parcelas de antecipação de pagamento já pode contar com uma geração de XML mais robusta no ACBr — evitando o envio de um grupo vazio que poderia comprometer a validação do documento. O grupo BB01 – gPagAntecipado, previsto na NT 2025/002 (versão 1.40), permite informar a(s) NF-e emitida(s) anteriormente referentes a pagamento antecipado, usada(s) para abater as parcelas correspondentes, conforme o Art. 10, §4º citado na própria norma. O ACBrNFe já conta com suporte a esse grupo desde a implementação das mudanças da Reforma Tributária no leiaute da NF-e. Uma correção recente no ACBrNFe.XmlWriter ajustou a geração para que o grupo só seja incluído no XML quando houver ao menos uma chave de referência (refNFe) cadastrada. A mudança evita a geração de um grupo gPagAntecipado vazio, o que poderia levar à rejeição do documento pela SEFAZ. Quem já utiliza o componente não precisa alterar nada na própria aplicação — basta seguir usando a mesma API para que o comportamento correto seja aplicado automaticamente. O que é o grupo gPagAntecipado Dentro das adequações trazidas pela Reforma Tributária ao leiaute da NF-e, a NT 2025/002 (versão 1.40) define o Grupo BB — Grupo de notas de antecipação de pagamento, dentro da tag Ide: ID Campo Ocorrência Tamanho Observação BB01 gPagAntecipado 0-1 — Informado para abater as parcelas de antecipação de pagamento, conforme Art. 10, §4º BB02 refNFe 1-99 44 Referência a uma NF-e (modelo 55) emitida anteriormente, referente a pagamento antecipado Ou seja: o grupo é opcional (ocorre 0 ou 1 vez), mas quando presente deve conter de 1 a 99 referências de chaves de acesso (refNFe), cada uma com 44 posições. É justamente essa regra — grupo presente exige ao menos uma referência — que motivou o ajuste no ACBr. O que foi corrigido A atualização mais recente no componente ACBrNFe ajustou a rotina responsável por montar esse trecho do XML: agora, o grupo gPagAntecipado só é criado quando a lista de referências (refNFe) contiver pelo menos um item. Antes dessa correção, o grupo podia ser gerado mesmo sem nenhuma chave informada — o que resultaria em uma tag sem o conteúdo obrigatório exigido pelo schema da NF-e, um cenário com risco real de rejeição no ambiente da SEFAZ. Esse tipo de ajuste é especialmente importante em componentes fiscais: pequenas inconsistências na geração de um grupo opcional podem gerar erros de validação difíceis de rastrear, principalmente em cenários de Reforma Tributária, onde o leiaute ainda está em consolidação. Como usar Quem já preenche os dados de identificação (Ide) da NF-e via ACBrNFe pode informar as referências de antecipação normalmente, adicionando um item à coleção para cada chave de acesso: with Ide.gPagAntecipado.refNFe.New do refDFEChave := '12345678901234567890123456789012345678901234'; with Ide.gPagAntecipado.refNFe.New do refDFEChave := '12345678901234567890123456789012345678904567'; Se nenhuma referência for adicionada à coleção refNFe, o grupo gPagAntecipado simplesmente não é gerado no XML — sem necessidade de nenhuma verificação manual por parte de quem integra o componente. Dica: esse mesmo trecho de código está disponível nos programas exemplo do ACBr (projeto ACBrNFe, arquivo Frm_ACBrNFe.pas, nas versões Delphi e Lazarus). Vale a pena consultar os exemplos sempre que for implementar um novo campo da Reforma Tributária — eles trazem casos de uso já testados e evitam retrabalho na hora de integrar o componente. Por que isso importa para quem emite NF-e Reduz o risco de rejeição do documento por inconsistência de schema em cenários de antecipação de pagamento. Mantém o componente alinhado à NT 2025/002 (versão 1.40), que segue sendo ajustada à medida que a Reforma Tributária avança. Preserva a simplicidade de uso: o desenvolvedor continua preenchendo apenas os dados que possui, sem precisar tratar manualmente o caso de lista vazia. Quem já utiliza o ACBrNFe para emissão de NF-e sob as regras da Reforma Tributária tem, portanto, mais um ponto de atenção resolvido pelo próprio componente — reforçando o papel do ecossistema ACBr como referência para adequação de sistemas fiscais em Delphi. Quer simplificar ainda mais a adequação do seu sistema às mudanças da Reforma Tributária na emissão de documentos fiscais? Conheça o ACBr PRO e conte com componentes sempre atualizados conforme as novas regras da NF-e. Fonte oficial: Nota Técnica 2025/002 (versão 1.40) da NF-e — Grupo BB (gPagAntecipado/refNFe); e changelog do componente ACBrNFe (registro de 30/06/2026) — correção em ACBrNFe.XmlWriter para geração condicional do grupo gPagAntecipado.

A receita federal, atendendo a pedido feito pelo Serpro sob a justificativa de melhor poder distribuir os procedimentos técnicos ao longo da implementação, divulgou uma antecipação do cronograma da implantação do CNPJ Alfanumérico. Das 21h do dia 23 de julho de 2026 (quinta-feira) até as 7h do dia 25 de julho de 2026 (sábado): A base de dados do CNPJ estará disponível apenas para consulta, sem a possibilidade de atualizações ou inclusões cadastrais. A partir das 7h do dia 25/07/2026 (sábado): A base ficará completamente indisponível. A partir das 7h do dia 27 de julho de 2026 (segunda-feira): Entrada em produção do sistema. Dia 31 de julho de 2026 (sexta-feira): Implementação do primeiro CNPJ alfanumérico. Mais informações podem ser encontradas no Portal do CNPJ Alfanumérico.

@xjonas117 você está usando os componentes, Lib ou ACBrAPI? Obrigado

Olá, comunidade ! Foi publicado no dia 15/07/2026 a versão 1.40 da Nota Técnica 2014/001 que traz definições sobre o Evento Prévio de Contingência (EPEC). Alterações Adiciona a seguinte rejeição relacionada ao PAA: Adiciona a seguinte regra de validação para barrar o uso do EPEC para os estados do PR e PB: De acordo com a NT, essa regra foi adicionada para atender ao Ajuste SINIEF Nº 25/2026. Datas Implantação Teste: 09/09/2026 Implantação Produção: 05/10/2026 E como fica o ACBr? Como a NT não traz nenhuma alteração de leiaute, não será necessário nenhuma modificação nos fontes do ACBr. Leia a versão 1.40 desta nota técnica na íntegra AQUI.

Suporte a DANFSe v2.0 (NT 008 SE/CGNFS-e) no motor FPDF Contexto / Motivação O leiaute do DANFSe para o Sistema Nacional NFS-e (Ambiente de Dados Nacional) mudou com a NT 008/SE-CGNFS-e — a versão anterior do ACBr.DANFSeX.FPDFA4Retrato (leiaute municipal/ABRASF) não é compatível com o layout exigido para proPadraoNacional. Este PR adiciona um renderer dedicado, no mesmo motor de relatórios (ACBr_fpdf_report/ACBr_fpdf_ext), sem introduzir dependência de bibliotecas de terceiros. Escopo Arquivo novo: Componentes/ACBr/Fontes/ACBrDFe/ACBrNFSeX/DANFSE/FPDF/ACBr.DANFSeX.FPDFPadraoNacional.pas Nova classe TACBrDANFSeFPDFPadraoNacional = class(TFPDFReport), ~1600 linhas. Segue a mesma convenção arquitetural de TACBrDANFSeFPDFA4Retrato (construtor Create(ANFSe: TNFSe), SalvarPDF overloads), mas com um pipeline de bandas (AddBand) próprio, mapeado 1:1 ao Anexo I da NT 008. Arquivos alterados: ACBrNFSeXDANFSeFPDFClass.pas — ExecutaImpressaoPDFUmaNFSe passa a bifurcar por Configuracoes.Geral.Provedor = proPadraoNacional, delegando para o novo renderer; demais provedores continuam no TACBrDANFSeFPDFA4Retrato (comportamento preservado, zero mudança de rota para quem já usa o leiaute municipal). Pacotes/Delphi/ACBrDFe/ACBrNFSeX/DANFSE/FPDF/ACBr_NFSeXDanfseFPDF.dpk — adicionada a unit nova ao contains. Decisões de design relevantes para revisão 1. Grade de campos sem bordas verticais (fidelidade ao gerador oficial) O PDF gerado pelo Sefin Nacional não desenha grade por célula — só linhas horizontais nos limites de bloco (btPageHeader a btPageHeader) e preenchimento cinza claro (5% K) na célula-título, sem traço vertical algum entre colunas (validado extraindo os page.get_drawings() de um PDF de referência real via PyMuPDF: 22 operações vetoriais na página inteira). A implementação original deste PR desenhava uma TFPDF.Rect completa por campo (~800 operações/página). Foi refeita para reproduzir o padrão oficial: DesenharCampo não desenha borda nenhuma (só preenchimento quando Sombreado=True); um único DesenharLinhaSeparadora (uma PDF.Line horizontal) fecha cada bloco. Cuidado de ordem de desenho: a linha separadora é emitida depois do preenchimento cinza do título de bloco (não antes) — como ambos ocupam Y=0 do banda, desenhar a linha primeiro faz o fill cinza pintar por cima e apagá-la. Resultado final: 24 operações/página (a diferença de 2 vs. o oficial é só o modo de desenho do próprio QR Code, ver item 4). 2. Motor de bandas (TFPDFReport/AddBand) Confirmado por leitura de ACBr_fpdf_report.pas: a altura passada a AddBand é a declarada, não a real desenhada — usada pelo motor para posicionar a próxima banda (DrawBand). Cada CalcAltura* precisa bater exatamente com o que o Banda* correspondente desenha, senão sobra/falta espaço entre blocos. btPageFooter ancora sempre no rodapé da página independente do conteúdo acima (DrawLastBands) — por isso todos os blocos fluem em btPageHeader (sequencial) exceto Informações Complementares (btData, altura dinâmica = espaço livre) e Canhoto (btPageFooter, fixo no rodapé), replicando o comportamento observado no gerador oficial (Informações Complementares estica até o Canhoto). 3. Logomarca — sem asset embutido, seguindo convenção já usada no ACBr LogoNFSe: string (caminho de arquivo ou conteúdo binário bruto) — mesmo nome/tipo já declarado em TACBrNFSeXDANFSeClass.LogoNFSe e mesma semântica de TDFeReportFortes.CarregarLogo (usado por NFe/CTe/MDFe/NF3e/NFCom). Sem valor padrão embutido: se vazio, o espaço do cabeçalho fica em branco. 4. QR Code Conteúdo montado a partir de cURLConsultaPublica + ChaveDeAcesso — TNFSe.Link não é preenchido pelo parser do Padrão Nacional (PadraoNacional.LerXml.pas), então o gate de exibição usa infNFSe.ID/ChaveAcesso, não Link. Desenhado via PDF.QRCode (módulo a módulo, retângulos vetoriais pretos) — diferente do PDF oficial, que parece embutir o QR como imagem rasterizada única. Funcionalmente equivalente (QR válido, testado com leitor), mas gera ~700 operações vetoriais extras por página; não normalizado neste PR — encaminhar como possível otimização futura se ACBr_fpdf_ext ganhar suporte a inserir QR como imagem. 5. Mapeamento de fontes NT 008 item 2.4 exige Arial (labels) e Microsoft Sans Serif (conteúdo) — nenhuma é fonte core do FPDF. Mapeadas para 'Arial' (alias interno resolvido para Helvetica core) até que TTFs sejam embarcadas via AddFont. Sinalizar para revisão: isso é uma aproximação visual, não 100% NT-008-literal; embarcar as TTFs certas teria implicação de licenciamento a avaliar antes. 6. Campos dinâmicos por bloco (Tomador/Destinatário/Intermediário/Tributação Municipal) Cada bloco tem duas formas de renderização: grade completa (quando há dado) ou uma única linha "vazia" central (DesenharLinhaVazia, sem grade, mensagem fixa conforme NT 008 itens 2.3/2.5 — ex. TOMADOR/ADQUIRENTE DA OPERACAO NAO IDENTIFICADO NA NFS-e), replicando o padrão do gerador oficial para blocos suprimidos. Exemplo de uso: program ExemploDANFSeComLogo; {$APPTYPE CONSOLE} uses SysUtils, Classes, ACBrNFSeX, ACBrNFSeXConversao, ACBrNFSeXDANFSeFPDFClass, ACBrNFSeXClass; var iNFSe: TACBrNFSeX; DANFSeFPDF: TACBrNFSeXDANFSeFPDF; begin iNFSe := TACBrNFSeX.Create(nil); DANFSeFPDF := TACBrNFSeXDANFSeFPDF.Create(nil); try iNFSe.DANFSE := DANFSeFPDF; iNFSe.SetProvedor(proPadraoNacional); // LogoNFSe e' herdada de TACBrNFSeXDANFSeClass (mesma propriedade usada // por NFe/CTe/MDFe/etc via TDFeReportFortes.CarregarLogo) - aceita // caminho de arquivo... DANFSeFPDF.LogoNFSe := 'C:\CargoPro\Recursos\logo-nfse-horizontal.png'; // ...ou, se preferir nao depender de um arquivo solto no disco, o // conteudo binario da imagem direto na string (ver CarregarLogoNFSeBytes // em ACBr.DANFSeX.FPDFPadraoNacional.pas: se FileExists falhar, o valor // e' tratado como o proprio conteudo do arquivo, nao um caminho): // // var // LogoBytes: TBytes; // begin // TFile.ReadAllBytes(...) ou carregar de um resource (RCDATA) do exe; // DANFSeFPDF.LogoNFSe := TEncoding.ANSI.GetString(LogoBytes); // cuidado com encoding, ver nota abaixo iNFSe.NotasFiscais.Clear; iNFSe.NotasFiscais.LoadFromFile('C:\CargoPro\exemplos\nfse\minha-nota.xml'); DANFSeFPDF.PathPDF := 'C:\CargoPro\Saida'; DANFSeFPDF.Sistema := 'CargoPro'; DANFSeFPDF.ImprimirDANFSe; WriteLn('OK -> ', DANFSeFPDF.ArquivoPDF); finally DANFSeFPDF.Free; iNFSe.Free; end; end. ACBrNFSeXDANFSeFPDFClass.pas ACBr.DANFSeX.FPDFPadraoNacional.pas ACBr_NFSeXDanfseFPDF.dpk

Olá, comunidade ! Ao acessar o Portal da Nota Fiscal Eletrônica, é possível observar que múltiplas UFs estão com contingência agendada para o dia 19/07/2026, com previsão de início às 06h30 e encerramento às 09h00 do mesmo dia. Para utilizar as soluções do ACBr em contingência siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação no canal #sefaz em nosso servidor do Discord.

Conforme orientação do Juliomar, efetuei a abertura de um chamado na SEFA/PR e a resposta foi a seguinte. “Prezado(a) Sr(a), O sincronismo das notas, entre os ambientes estadual e nacional, ocorre através de um processo automatizado. Entretanto, esse processo teve problemas, no dia: 06/07/2026 e que já foi corrigido. Devido ao problema, acumulou-se uma fila (atraso) no processo automático - o que explica-se o fato da divergência entre os ambientes. Aos poucos, o processo automatizado, deverá consumir a fila. Entretanto, sem previsão para tal, devem aguardar Atenciosamente, Serviço de Atendimento ao Cidadão da Receita Estadual do Paraná”

@Daniel Simoes aparentemente está certo agora, testei reimpressões e não acusou transação pendente ao iniciar a aplicação. Obrigado !

SIM. EXATAMENTE O QUE EU ESTAVA TE FALANDO. BOM TARBALHO!

O município de São Paulo /SP está como NÃO na parte de adesão(emissão direta pelo padrão), como havia lhe perguntado antes.. Para esse município, você Irá continuar emitindo com o layout de provedor, só precisa passar os campos da Reforma Tributária igual, se os schemas do seu provedor já estiverem adequados a isso. De novo... Para esse município, você precisa continuar enviando a NFSe pelo provedor. Deverá somente preencher as tags NFSe.IBSCBS

Boa tarde @marcelo.hgv, O teste que eu fiz neste momento foi usando o programa exemplo em Delphi, veja o resultado: Você utiliza Delphi ou Lazarus? Como que esta o Zoom (100%) ?

Boa tarde, pessoal! Relacionei este tópico à tarefa ACBR-9498. Quando ela estiver concluída, avisaremos aqui. Atualizando o status da tarefa: ela se encontra na sprint atual e em breve deve ser analisada.

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

Bom dia, qual município está querendo emitir a NFSe? Enquanto o municípo não estitiver na condição a baixo, vai precisar emitir sempre como o provedor. Somente funciona emitir nfse pelo padrão nacional se o municipio já estiver cadastrado completamente lá. Seu municipio vai continuar recebendo as nfse e eles transmitindo para o padrão nacional ? Se for o caso, você vai continuar a emitir pelo provedor, só precisa passar os campos que a prefeitura necessitar Segue link para verificar como está os status do municipios em relação a emissão direta pelo padrão nacional: https://app.powerbi.com/view?r=eyJrIjoiNGQ4YTcxNmMtMzdhNC00Mzc5LTllM2EtMjY1MTM3NWQyZDgyIiwidCI6IjZmNDlhYTQzLTgyMmEtNGMyMC05NjcwLWRiNzcwMGJmMWViMCJ9&pageName=608609c2e0a53d7a3c6e Se na aba "Adesão ao emissor Nacional da NFSe*" Estiver aparecendo SIM este municipio pode comunicar diretamente com o padrão nacional(eu estou configurando da seguinte forma): ACBrNFSeX1.Configuracoes.Geral.LayoutNFSe := lnfsPadraoNacionalv101; ACBrNFSeX1.Configuracoes.Geral.Versao := ve101; ACBrNFSeX1.Configuracoes.Geral.CodigoMunicipio := CodIBGE; Se na aba estiver NÃO então precisa emitir via Provedor, como antigamente.. a própria ACBR passa/pega o provedor necessário, de acordo com o municipio do emitente: ACBrNFSeX1.Configuracoes.Geral.LayoutNFSe := lnfsProvedor; ACBrNFSeX1.Configuracoes.Geral.CodigoMunicipio := CodIBGE;

Muito obrigado pela contribuição @Leonardo Gregianin @Alexandre de Paula, creio que já temos uma tarefa para essa finalidade... Essa contribuição irá nos ajudar muito

A Origem do problema está nessa função Correção em Azul: function TNFeXmlReader.ObterConteudo(const ANode: TACBrXmlNode; const Tipo: TACBrTipoCampo): variant; begin Result := inherited ObterConteudo(ANode, Tipo); if Tipo in [tcStr] then Result := ParseText(Result) else if Tipo in [tcEsp, tcStrOrig] then Result := ParseText(Result, False); end;

Bom dia. Atualizei os fontes e o DANFSe está só faltando 2 detalhes no meu ponto de vista. Logo sendo cortado: Canhoto desalinhado: Em meu arquivo acima tem uma correção para o alinhamento do canhoto. Espero que ajude.

Olá pessoal, Foram disponibilizados na Rev-47223 os programas de exemplo em PHP, Singlethread e Multithread utilizando a ACBrLibCIOT. ..\ACBr\Projetos\ACBrLib\Demos\PHP\CIOT\ACBrCIOTDemoST.php ..\ACBr\Projetos\ACBrLib\Demos\PHP\CIOT\ACBrCIOTDemoMT.php Lembrando que os programas de exemplo em php utilizam a ACBrComum.php que contém métodos em comum entre os modos (ST e MT) e para todas as libs. ..\ACBr\Projetos\ACBrLib\Demos\PHP\ACBrComum\ACBrComum.php Até mais!!!

Boa tarde a todos, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e façam novos testes.

Olá, comunidade ACBr! Ficamos felizes em anunciar o lançamento da ACBrLibCIOT! Baixe a ACBrLibCIOT: Na versão DEMO Na versão PRO Leia a documentação completa AQUI Até mais!!!

Pessoal, descobri o motivo, caso alguem passe por isso, principalmente no estado de Goias, eu liguei no (62) 3269-2000 QUE E SECRETARIA DO ESTADO DE gOIAS, e eles me informaram que pode acontecer isso caso o destinatario precisa as vezes fazer o sicronismo com eles, ai a gente passa o CNPJ e a Inscricao estadual pra eles fazer esse processo de sincronismo, ai so depois desse processo meu cliente conseguiu gerar a Nota para o seu cliente

Olá comunidade ! Ao acessar a página da documentação da NFS-e Nacional, no dia 15/07/2026, haviam novas observações detalhando um pouco mais o cronograma dessa NT:

Olá, comunidade ! Ao acessar a página de notícias do Portal do GNRe, consta a seguinte notícia publicada em 14/07/2026 informando que desde às 14h00 do mesmo dia até às 17/07/2026 o a emissão de GNRe via web service para o RN está indisponível devido a processo de manutenção e melhorias:

Boa tarde. Só para registro, segue resposta da SEFAZ no chamado que eu havia criado semana passada, onde confirmam que o problema era do lado deles. att, Leandro

Olha, eu não preencho esses campos que tu está usando.... Nem seto nada disso: Servico.LocalPrestacao := lpForaMunicipio e já fizemos testa para gente de fora Servico.CodigoMunicipio:= CDIBGE try Servico.CodigoPais := CDPAIS except Servico.CodigoPais := 1058; // Brasil end; Servico.xPais := DSC_PAIS Servico.MunicipioIncidencia := StrToIntDef(Servico.CodigoMunicipio, 0); //MEESMO CAMPO DE ANTES (CDIBGE) Servico.UFPrestacao := UF E preenchendo isso, está ficanco certo

Li só o título, não vi a qual grupo se referia

Obrigado por responder Juliomar, vou abrir o chamado, meu objetivo a ajudar a comunidade a não ficar batendo cabeça a toa com este tipo de problema.

Olá Pessoal, O uso do Padrão Nacional é um movimento crescente, começando com sua obrigatoriedade para os MEIs em 2023, sua próxima obrigatoriedade para os prestadores enquadrados no Simples Nacional agora em 2026 (veja mais sobre isso aqui) e o fato de todos os 5.571 municípios terem se conveniado, seja para realizar a emissão direta ou via compartilhamento de informações. Diferente de situações anteriores, a prerrogativa de "padrão" implica em uma padronização única. Isso se aplica inclusive ao próprio leiaute do DANFSe. Onde anteriormente não havia nenhuma regulamentação ou orientação sobre como deve ser o leiaute do impresso, hoje existem definições explícitas com a publicação da Nota Técnica Nº008, estabelecendo parametrizações como o que pode constar no impresso, o que não pode e como as informações devem ser exibidas nele. A equipe do ACBr já adaptou o impresso em Fortes para atender a essas definições e está trabalhando arduamente para disponibilizar os impressos em Fast e em FPDF. Levando tudo isso em consideração, informamos que os esforços a partir de agora serão focados em manter o DANFSe atendendo à NT Nº008 ou qualquer publicação futura relacionada e, por isso, não serão feitas novas alterações no DANFSe utilizado para os provedores no leiaute da ABRASF e em leiautes próprios. Ressaltamos que, na conjuntura atual, mesmo os municípios que aderiram apenas ao compartilhamento e vão continuar utilizando provedores próprios já têm disponibilizado em seus arquivos XML e retornos do web service os meios para que o XML da NFS-e compartilhado no ambiente nacional seja acessado e, de posse desse XML, o DANFSe no leiaute estabelecido pela NT Nº008 pode ser utilizado. Agradecemos a compreensão de todos.

ACBrBPe é atualizado: fim da dependência da PCN e novas units para a Reforma Tributária O componente ACBrBPe passou por mudanças estruturais importantes — a remoção da dependência das units da PCN e a adoção de units específicas da Reforma Tributária. Confira o que muda no seu código. Resumo da atualização: O ACBrBPe não depende mais de nenhuma unit da PCN Quatro tipos de propriedades foram renomeados (veja tabela abaixo) A função StrToTpAmb foi substituída por StrToTipoAmbiente Todos os novos tipos e funções de conversão agora estão centralizados em ACBrDFe.Conversao O componente passou a utilizar units específicas da Reforma Tributária, reduzindo a quantidade de código Um episódio do Papo PRO ACBr detalha essas novas units da Reforma Tributária O que mudou no ACBrBPe O componente ACBrBPe (Bilhete de Passagem Eletrônico) deixou de utilizar qualquer unit da PCN. Como consequência direta dessa mudança estrutural, alguns tipos de propriedades precisaram ser substituídos por equivalentes próprios do ACBr. Tipos e funções renomeados Se o seu projeto utiliza o ACBrBPe, é necessário ajustar as referências aos tipos abaixo: Antes Agora TpcnTpEvento TACBrTipoEvento TTipoEmissao TACBrTipoEmissao TpcnTipoAmbiente TACBrTipoAmbiente TpcnTipoImpressao TACBrTipoImpressao StrToTpAmb (função) StrToTipoAmbiente (função) Todos esses tipos e funções de conversão agora estão declarados na unit ACBrDFe.Conversao. Um exemplo de ajuste no código seria: uses ACBrDFe.Conversao; var TipoAmbiente: TACBrTipoAmbiente; begin TipoAmbiente := StrToTipoAmbiente('1'); end; Quem mantém código legado com os tipos antigos deve atualizar as referências antes de compilar novas versões do componente. Units específicas da Reforma Tributária Além da limpeza de dependências, o ACBrBPe passou a utilizar units específicas voltadas à Reforma Tributária, o que reduziu significativamente o código interno do componente. Essa é uma frente que o ACBr vem consolidando em diversos componentes fiscais, padronizando o tratamento de IBS, CBS e demais exigências da nova legislação tributária. Para entender em detalhes como essas novas units funcionam e o que elas representam para o ecossistema ACBr, o episódio do Papo PRO ACBr disponível no Spotify traz uma explicação completa sobre o tema. Encontrou algum problema? Alterações estruturais como essa podem impactar projetos em produção. Caso identifique qualquer inconsistência após a atualização do ACBrBPe, é fundamental abrir um tópico específico descrevendo o problema encontrado, para que a equipe possa avaliar e corrigir rapidamente. Ficar por dentro dessas mudanças é essencial para manter seus sistemas fiscais sempre compatíveis com as últimas exigências — inclusive as da Reforma Tributária. Quer contar com suporte especializado, atualizações prioritárias e acesso a conteúdos como o Papo PRO ACBr? Conheça o ACBr PRO e simplifique a manutenção dos seus componentes fiscais. Fonte oficial: Comunicado da equipe de desenvolvimento do projeto ACBr sobre a atualização do componente ACBrBPe. Saiba mais no episódio do Papo PRO ACBr:

Muito obrigado @marcosvillatore... @Daniel InfoCotidiano, acho que você está com essa tarefa, correto ?

Ainda não foi disponibilizado .está sendo implementado e testado

tudo via api

Inclusão do método SalvarPDF nas classes C# Olá comunidade! Visando manter a estabilidade e segurança das classes C# adicionaremos o método SalvarPDF Nossa recomendação para as classes MDFe, NFe e NFSe é a utilização do método SalvarPDF() ao invés do ImprimirPDF(Stream aStream); A motivação dessa mudança é que esse método utiliza operações assíncronas e pode causar Condição de Corrida. Além disso, mantém coerente a documentação da ACBrLib Se utiliza classes C# MT deve atualizar os pacotes o mais breve possível. Diferente de ImprimirPDF(Stream aStream), o SalvarPDF retorna uma String com o conteúdo do PDF em base64. Até a data da publicação desse tópico foram atualizados: Atualizado em 14/07/2026 NFe versão 1.0.37 MDFe versão 1.014 NFSe versão 1.0.17 CTe versão 1.0.14 Boleto versão 1.0.34 Exemplo de código antigo: // exemplo de código antigo Stream ms = new Stream() nfe.ImprimirPDF(ms); Código recomendado: string pdfStream = nfe.SalvarPDF(); Boleto: Código antigo // exemplo de código antigo usando Stream Stream ms = new Stream() boleto.GerarPDF(ms); // boleto indexado usando Stream Stream ms2 = new Stream(); boleto.GerarPdf(0, ms2); Código recomendado: // código atual string pdfStream = boleto.SalvarPDF(); string pdf = boleto.SalvarPDF(0);

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.