Painel de líderes

Olá pessoal, Foi feita uma alteração no DANFSE em Fortes Report, mais precisamente no DANFSE do Padrão Nacional. Em breve teremos essa mesma alteração em Fast Report e FPDF. Agora o componente vai se utilizar de um dos dois logos oficiais que se encontram na documentação da NFS-e Padrão Nacional. Logos da NFS-e — Portal da Nota Fiscal de Serviço eletrônica Temos o Logo Horizontal e o Vertical, se o componente não for configurado ou a configuração estiver errada ele assume o Logo Horizontal. Como configurar o Logo da NFS-e? Delphi/Lazarus: // Utilize uma das 2 string: ACBrNFSeXLogoH; ACBrNFSeXLogoV ACBrNFSeX1.DANFSE.LogoNFSe := 'ACBrNFSeXLogoH'; ACBrLibNFSe: ACBrMonitor Plus:

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!!!

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.

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.

DANFe Simplificado Tipo 2: Sefaz publica as Notas Técnicas 2026/002 e 2026/003 e muda a impressão de NF-e e NFC-e A Sefaz definiu o leiaute e as regras operacionais do novo DANFe Simplificado Tipo 2. Entenda o que muda, os prazos de implantação e por que o mercado ainda precisa ficar atento antes de sair adequando os sistemas. Atenção! Aqui vale um alerta importante: embora o desenvolvimento esteja avançando, há diversos relatos na comunidade de que os ambientes da Sefaz ainda não estão aceitando de forma consistente o novo modelo de impressão para emissão de notas fiscais. Isso é comum em mudanças de leiaute recém-publicadas — a homologação e o comportamento do ambiente de produção das Secretarias de Fazenda estaduais costumam levar um tempo para acompanhar a própria nota técnica. Na prática, isso significa que testar o novo layout agora não substitui o acompanhamento contínuo do assunto até que a aceitação esteja de fato estabilizada. Resumo rápido A Nota Técnica 2026/003 v1.00 define o leiaute técnico e operacional do DANFe Simplificado Tipo 2, instituído pelo Ajuste SINIEF nº 13, de 6 de abril de 2026. A Nota Técnica 2026/002 v1.00 trata das regras de uso desse novo DANFe em operações presenciais e não presenciais, atendendo aos Ajustes SINIEF nº 32/25 e nº 13/26. O novo documento passa a cobrir com NF-e operações que hoje tipicamente usam NFC-e — mas o XML continua sendo o documento fiscal válido; o DANFe é só a representação impressa. Implantação em teste a partir de 01/07/2026 e em produção a partir de 03/08/2026 para a maior parte das mudanças (algumas regras têm cronograma próprio — veja a tabela abaixo). A implementação nas soluções ACBr já está em andamento, mas relatos da comunidade indicam que o ambiente da Sefaz ainda não está aceitando de forma consistente o novo modelo de impressão — ou seja, calma antes de sair trocando tudo em produção. O que é o DANFe Simplificado Tipo 2? O DANFe Simplificado Tipo 2 é um novo documento fiscal auxiliar, criado para padronizar a emissão de NF-e em operações que normalmente seriam cobertas por NFC-e. Assim como os demais modelos de DANFe já conhecidos pelo mercado, ele segue algumas regras básicas: É apenas a representação simplificada da operação — o XML continua sendo o documento fiscal de fato. A impressão é feita pelo próprio sistema do contribuinte, em impressora comum (não fiscal), com base nos dados do XML. Ele não pode conter nenhuma informação que não esteja no XML da NF-e correspondente. O leiaute definido pela NT 2026/003 organiza o documento em blocos que vão desde o cabeçalho e os itens da nota até a consulta por chave de acesso ou QR Code, informações do consumidor, dados de autorização e as novas informações de IBS/CBS, além do aviso exigido pela Lei Federal nº 12.741/2012 (a "lei da transparência fiscal"). O que muda na prática com a NT 2026/002 Enquanto a NT 2026/003 cuida do layout, a NT 2026/002 regulamenta como e quando esse novo DANFe pode ser usado. Os principais pontos: Alerta em vez de rejeição: é criado o novo cStat 120 – "Autorizado o uso da NF-e com alerta". Ele permite que a Sefaz autorize o documento mesmo diante de alguma inconsistência, sinalizando o problema em vez de simplesmente rejeitar a nota. Por enquanto, esse cStat vale só para NFC-e. Alerta de CNPJ irregular: passa a haver um aviso na emissão de NFC-e quando o destinatário for identificado por CNPJ em situação irregular. Vedação de referência cruzada: NF-e de saída não pode mais referenciar NFC-e ou CF-e, exceto quando se tratar de NF-e complementar. Contingência off-line regulamentada para a NF-e emitida com DANFe Simplificado Tipo 2. Regras que hoje valem só para a NFC-e (modelo 65) passam a valer também para a NF-e (modelo 55) — por exemplo, verificação de data de entrada/saída, tipo de operação e se a operação é interestadual ou com o exterior. O limite de R$ 10.000,00 para emissão de NFC-e sem identificação do destinatário continua valendo por padrão, mas a Sefaz vai publicar uma tabela com valores específicos por UF. No campo técnico, a NT também altera valores de campos já conhecidos do leiaute: o tpImp ganha o valor 6 (DANFe Simplificado Tipo 2), o indPres tem a descrição do valor 4 ajustada, e o tpEmis tem a descrição do valor 9 atualizada para contemplar a contingência off-line desse novo modelo. Cronograma de implantação Mudança Teste Produção Leiaute do DANFe Simplificado Tipo 2 (NT 2026/003) 01/07/2026 03/08/2026 Regra de emissão de NFC-e sem identificação do destinatário 01/06/2026 15/06/2026 Regras de validação para NF-e e rejeição de referência aos modelos 65/59 01/07/2026 03/08/2026 Estrutura de autorização com alertas e demais regras de validação 01/09/2026 05/10/2026 Vale reparar que as datas não são únicas: a mudança chega em ondas, o que dá algum fôlego para adequação — mas também exige atenção redobrada, já que cada regra entra em vigor em um momento diferente. O ACBr já está pronto? E a Sefaz? Do lado do desenvolvimento, o novo leiaute já está sendo trabalhado nas soluções ACBr — a NT 2026/003 está sendo acompanhada internamente pela tarefa ACBR-9424, e as mudanças da NT 2026/002 pela tarefa ACBR-9423. Quem utiliza os componentes de NF-e e NFC-e do ACBr deve acompanhar essas atualizações, já que a implementação do DANFe Simplificado Tipo 2 tende a chegar como parte natural da evolução desses componentes. Como se preparar Acompanhe os tópicos oficiais da NT 2026/002 e da NT 2026/003 no fórum do ACBr para novidades sobre a implementação. Não migre sistemas para produção com o novo layout sem antes validar o comportamento no ambiente de testes da Sefaz do seu estado. Fique atento às datas de cada regra — a rejeição de NF-e referenciando modelos 65/59 e as novas regras de validação chegam em momentos diferentes do leiaute do DANFe em si. Se seu sistema opera perto do limite de R$ 10.000,00 para NFC-e sem identificação do destinatário, monitore a publicação da tabela de valores por UF. Revise processos de contingência off-line, já que a NT 2026/002 regulamenta especificamente esse cenário para o novo modelo. Fonte oficial Informações baseadas nas publicações da comunidade do Projeto ACBr no fórum "Notícias do ACBr": Nota Técnica 2026/003 v1.00 — DANFe Simplificado Tipo 2 (Ajuste SINIEF nº 13/2026): Publicada NT que define leiaute do DANFe Simplificado Tipo 2 Nota Técnica 2026/002 v1.00 — Operações presenciais e não presenciais com DANFe Simplificado Tipo 2 (Ajustes SINIEF nº 32/25 e nº 13/26): Publicada Nota Técnica que cria NF-e "sabor" NFC-e Quer se antecipar a essas mudanças fiscais? Ficar por dentro de cada nota técnica é só o primeiro passo — o desafio real é manter seu sistema emissor sempre atualizado sem virar um projeto interminável. Conheça o ACBr PRO e simplifique a adequação da emissão de NF-e, NFC-e e dos demais documentos fiscais eletrônicos do seu sistema.

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.

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.

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!!!

@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.

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á”

Olá, comunidade ! No dia 14/07/2026, por volta das 9h49, começamos a receber relatos de membros da nossa comunidade com problemas na emissão de notas fiscais de serviço para o município de São Paulo. Os relatos informavam que, ao tentar se comunicar com o web service, era devolvido timeout. Realizando testes, o timeout foi constatado mesmo com um valor de 60 segundos configurado na propriedade de timeout do componente. Ao acessar a URL diretamente pelo navegador, a URL também apresentou lentidão. Buscando mais informações sobre o problema, ao acessar a página da Nota Fiscal Paulistana, foi observado o seguinte aviso informando manutenção programada para hoje:

Veja que o Diego esclareceu acima. Usando ACBrAPI você vai conseguir emitir usando o ambiente de produção. Solicite ao seu cliente e caso queira testar é possivel emitir uma nota de baixo valor em produção e cancelar depois. Recomendamos entrar em contato com a prefeitura e com o provedor ISSNet para entender o ambiente deles e solicitar apoio e esclarecimentos.

Olá pessoal! Reportando que o comportamento mencionado anteriormente ainda persiste testando depois das 17h do dia 16/07/2026

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á 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!!!

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:

Boa tarde Gostaria de solicitar a atualização do arquivo "PadraoNacional.GravarXml.pas", da pasta "\Fontes\ACBrDFe\ACBrNFSeX\Provedores", para o Trunk do projeto A mudança consiste em mover o bloco responsável pela escrita da tag "tpRetPisCofins", parte da hierarquia "NFSe/infNFSe/DPS/infDPS/valores/trib/tribFed/piscofins/" Para fora da condição "if not (NFSe.Servico.Valores.tribFed.CST in [cst00, cst08, cst09]) then", resultando em: Isso se deve em função de cenários específicos em que há PIS e COFINS retidos. Mais especificamente, são situações em que é preciso indicar o valor das retenções de PIS/COFINS/CSLL na tag "vRetCSLL" que como indicado na versão 1.03.00 do Anexo VI da NFSe, ele representa a soma das retenções de acordo com o indicado na tag "tpRetPisCofins". Por exemplo, quando utiliza-se o tipo "3 - PIS/COFINS/CSLL" retidos, torna-se necessário indicar a tag "tpRetPisCofins" com o valor "3" e o campo "CST" com o valor "00 - Nenhum" pois não há um valor de PIS e COFINS de apuração própria para ser usado o CST "01 - Operação Tributável com Alíquota Básica" e preenchidos os demais campos (vBCPisCofins, pAliqPis, pAliqCofins, vPis e vCofins) O entendimento de que os campos "vPis" e "vCofins" não devem ser usados em casos de retenção, vem do texto que faz parte da Nota Técnica SE/CGNFS-e nº 007 (https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc/nt-007-se-cgnfse-v1-0.pdf), transcrito abaixo e que indica claramente a distinção entre os valores de PIS e COFINS retidos e de apuração própria Então ao manter a geração da tag "pRetPisCofins" como parte da condição "if not (NFSe.Servico.Valores.tribFed.CST in [cst00, cst08, cst09]) then" isso impede que seja usada a retenção de PIS e COFINS com o CST "00 - Nenhum" para o PIS/COFINS Abaixo está a imagem do anexo VI da NFSe (versão 1.03.00 atualizado pela Nota Técnica SE/CGNFS-e nº 007) para facilitar a correlação com as tags que descrevi nos dois parágrafos acima Eu realizei essa alteração que descrevi e pude autorizar uma nota em ambiente de produção do serviço nacional, então posso confirmar que, no presente momento, ela é permitida. Em anexo está o arquivo fonte alterado a partir da revisão 47144, mas se preferir alterar manualmente, basta fazer a cópia da linha referente ao "tpRetPisCofins" que descrevi no começo do tópico PadraoNacional.GravarXml.pas

Boa tarde, Foi criada a tarefa ACBR-9637 para avaliação. Obrigada pela contribuição!

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

@leomcl Creio que o ideal seria aguardar os schemas atualizados, pois devem estar aptos aos cnpjs alfanuméricos. Vi que disponibilizaram dia 10/07, vou fazer um teste aqui. Att.

Tarefa ACBR-9423 concluída e no SVN.

NFS-e Via: nova API permite consultar alíquotas de ISS por trecho e data A Secretaria-Executiva do Comitê Gestor da NFS-e ampliou as ferramentas de transparência do sistema NFS-e Via. Entenda o que muda para as Administrações Tributárias Municipais e onde a comunidade pode ajudar a levar essa novidade também para o ecossistema ACBr. Resumo da novidade: Foi publicada a versão 1.1 do Anexo V – Guia para Utilização das APIs, destinada às Administrações Tributárias Municipais do sistema NFS-e Via; A principal novidade é a API de consulta de alíquotas de ISS por trecho e data; Os municípios passam a acessar o histórico e a vigência das alíquotas aplicadas em trechos de concessões rodoviárias; A resposta traz percentual de participação de cada município, alíquota base, alíquota efetiva municipal e alíquota efetiva total do trecho; O objetivo declarado é aumentar a transparência e facilitar a validação do rateio do ISSQN entre os entes federados; A documentação técnica e os ambientes de teste já estão disponíveis para integração. O que mudou na NFS-e Via O NFS-e Via é a frente do sistema nacional da Nota Fiscal de Serviço eletrônica voltada às concessionárias de exploração de vias — o modelo usado para emitir a nota fiscal referente à cobrança de pedágio. Como o trecho de uma concessão costuma atravessar mais de um município, o ISS arrecadado precisa ser rateado entre eles, de acordo com a extensão da rodovia em cada território e a alíquota vigente em cada localidade. Até então, o Anexo V – Guia para Utilização das APIs descrevia apenas o método ObterDocumentos, usado pelos municípios para baixar os XMLs de NFS-e Via e de eventos de cancelamento por NSU, além da consulta de alíquotas por município. Com a versão 1.1, publicada em julho de 2026, o guia passa a contemplar também a consulta de alíquotas por trecho em uma data específica. Como funciona a nova consulta de alíquotas O novo endpoint, GetAliquotasTrecho, é acessado via GET /Aliquotas/trecho/{codigoTrecho}/dataReferencia/{dataReferencia} e retorna, para um trecho e uma data de referência informados, a lista completa de municípios envolvidos no rateio, com: extensão do trecho em cada município e o percentual correspondente; alíquota de ISS informada e a alíquota efetiva aplicada por município; a alíquota efetiva total do trecho, já consolidada. Essa informação se soma à consulta já existente por município (GetAliquotasMunicipioPorTrecho), que lista todos os trechos associados a um determinado código de município. Na prática, o município passa a poder conferir não só "quais trechos me afetam", mas também "qual era a alíquota vigente em uma data específica" — algo essencial para auditar cobranças passadas ou resolver divergências de repasse. Todas as comunicações continuam seguindo o padrão já estabelecido para o NFS-e Via: API REST síncrona, mensagens em JSON, documentos fiscais em XML 1.0/UTF-8, e autenticação mútua via certificado digital ICP-Brasil (TLS 1.0 a 1.2). Os ambientes de homologação, produção restrita e produção continuam disponíveis para testes de integração, com Swagger publicado para cada um deles. Por que isso importa para os municípios O rateio do ISS entre municípios cortados por uma mesma via é, por natureza, uma operação sensível: pequenas diferenças de alíquota ou de data de vigência mudam o valor final que cada prefeitura recebe. Ao expor essa informação via API — e não apenas em relatórios estáticos —, o Comitê Gestor da NFS-e permite que cada Administração Tributária Municipal audite o cálculo por conta própria, comparando o valor recebido com a alíquota que realmente estava vigente na data da cobrança do pedágio. Isso é particularmente relevante em disputas ou revisões de rateio: em vez de depender de uma consulta manual à concessionária, o município consulta diretamente o Ambiente Nacional da NFS-e Via e obtém o dado oficial. Onde ainda faltam ferramentas — um convite à comunidade Documentos fiscais eletrônicos como o NFS-e Via costumam ganhar, com o tempo, componentes prontos que facilitam a integração para quem desenvolve sistemas — é o caso de vários documentos já cobertos pelo ecossistema ACBr. Essa API específica de alíquotas do NFS-e Via, no entanto, ainda não tem um componente ACBr dedicado. A criação desse suporte está no roadmap do projeto, mas ainda sem previsão específica de entrega. É justamente aí que a comunidade pode fazer a diferença: quem já trabalha com integrações para concessionárias de vias ou tem interesse no tema pode contribuir com o desenvolvimento desse componente, ajudando a antecipar essa entrega para quem depende dela no dia a dia. Onde acessar a documentação A documentação técnica completa — incluindo os endpoints de obtenção de documentos e as duas consultas de alíquotas — está disponível no Anexo V – Guia para Utilização das APIs, com ambientes de homologação, produção restrita e produção liberados para testes de integração. Se você desenvolve integrações fiscais e quer ajudar a preencher essa lacuna no ecossistema ACBr — seja com o componente do NFS-e Via, seja com a consulta de alíquotas por trecho —, essa é uma boa oportunidade de contribuir com o projeto e com quem depende dele. Conheça as APIs do projeto ACBr e veja como participar do desenvolvimento junto com a comunidade. Fonte oficial: Secretaria-Executiva do Comitê Gestor da NFS-e — NFS-e Via: Publicada nova API para consulta de alíquotas do ISS, publicada em 10/07/2026.

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);

Bom dia, campo foi trocado por "adRemIS"

tava vendo isso quando vc mandou a mensagem vou baixar a nova contribuição. Obrigado.

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%) ?

Olá, pessoal. Estou com um cliente que está homologando o boleto via API do Itau e está recebendo a seguinte mensagem : Versão não implementada ou descontinuada pelo banco. Identificamos que a API antiga itau-ep9-gtw-pix-recebimentos-conciliacoes-v2-ext está em desativação e que a nova API é a Bolecode Pix v1.0.4. Consultamos estes tópicos: https://www.projetoacbr.com.br/forum/topic/91840-desativa%C3%A7%C3%A3o-itau-ep9-gtw-pix-recebimentos-conciliacoes-v2-ext/ https://www.projetoacbr.com.br/forum/topic/92306-aten%C3%A7%C3%A3o-descontinua%C3%A7%C3%A3o-do-endpoint-atual-da-api-bolecode-bolecode-pix-do-ita%C3%BA-nova-api-de-boleto-hibrido-dispon%C3%ADvel-para-testes/ No tópico sobre Bolecode Pix foi citada uma versão atualizada da ACBrBoletoW_Itau_API.pas, mas ainda não foi incorporada ao SVN. Poderiam, por gentileza, esclarecer: Existe previsão para disponibilizar a implementação oficial da nova API Bolecode Pix no SVN do ACBr? A unit disponibilizada no tópico é a mesma base que será incorporada ao SVN ou ainda pode sofrer alterações relevantes? É seguro utilizá-la em produção? Há dependências ou outras units que também precisam ser atualizadas? Além da troca de endpoint, há alguma alteração obrigatória em autenticação/escopos, certificado/CA ou payload que devemos considerar? Nosso objetivo é planejar a atualização com segurança, pois o sandbox do Itaú está instável/indisponível e a validação final tende a exigir emissão controlada em produção. Obrigado!

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

O que é o CIOT? CIOT é a sigla para Código Identificador da Operação de Transporte. Esse é um código gerado para registrar operações de transporte rodoviário remunerado de cargas junto à ANTT (Agência Nacional de Transportes Terrestres). Ele é obrigatório para o controle e rastreabilidade dessas operações no território nacional. Atualmente a regulamentação mais recente relacionada a ele sendo a Resolução nº 6.078, de 24 de março de 2026. O CIOT é uma novidade? Não. O CIOT já existe desde 2011. No entanto, quando foi estabelecido, seu uso era obrigatório apenas em operações de transporte muito específicas. Esse cenário mudou em 2026 com a Resolução nº 6.078, de 24 de março de 2026, que efetivamente tornou o CIOT obrigatório em praticamente todas as operações de transporte rodoviário remunerado de cargas. Veja abaixo a evolução da legislação: Quem deve gerar o CIOT? A Resolução nº 6.078/2026 estabeleceu em seu Art. 1º-A que toda operação remunerada de transporte rodoviário de cargas deverá ser registrada por meio de um CIOT, delegando a responsabilidade pela sua geração conforme a tabela abaixo: Operação de Transporte Responsável pelo CIOT Quando há contratação de TAC ou TAC Equiparado Contratante/Subcontratante Quando NÃO há contratação de TAC ou TAC Equiparado A própria ETC O que significam os termos TAC, TAC Equiparado e ETC mencionados acima? TAC é a sigla para Transportador Autônomo de Cargas. É a pessoa física que realiza o transporte rodoviário de cargas como atividade profissional. ETC é a sigla para Empresa de Transporte Rodoviário de Cargas. É a pessoa jurídica que tem como atividade principal o transporte rodoviário de cargas. TAC Equiparado é a denominação dada à ETC que possui em sua frota até 3 veículos registrados junto ao Registro Nacional de Transportadores Rodoviários de Cargas (RNTRC), bem como às Cooperativas de Transporte de Cargas, que também se enquadram nessa categoria. TAC Agregado é o Transportador Autônomo de Cargas que coloca veículo de sua propriedade ou posse — conduzido por ele mesmo ou por um preposto — a serviço de um contratante em regime de exclusividade, mediante remuneração previamente acordada. IPEF é a sigla para Instituição de Pagamento Eletrônico de Frete. É a instituição regulamentada pela ANTT responsável por realizar o pagamento eletrônico do frete e vinculá-lo à operação de transporte remunerado correspondente. Além disso, a IPEF participa do arranjo de pagamentos instantâneos instituído pelo Banco Central do Brasil, o que na prática significa que o pagamento do frete pode ser realizado via Pix. Devo gerar o CIOT quando a empresa possui frota própria e motoristas empregados? Sim, quando a empresa presta transporte rodoviário remunerado de cargas para terceiros. Ter frota própria e motoristas empregados não caracteriza, por si só, a operação como transporte de carga própria. Se a empresa transporta cargas ou encomendas de terceiros mediante remuneração, trata-se de uma operação de transporte por conta de terceiros, e o CIOT deve ser gerado conforme a regulamentação vigente. Por outro lado, se a carga transportada é da própria empresa, sem prestar serviço a terceiros e sem recebimento de frete, a geração do CIOT não é necessária. Como faço para gerar o CIOT? A geração do CIOT é feita de formas distintas dependendo de quem é o responsável pela operação. Se houve contratação de TAC ou TAC Equiparado, o CIOT deve ser gerado por uma das IPEFs habilitadas pela ANTT, por meio de portal próprio ou integração direta via web service disponibilizado pela própria IPEF. Caso a ETC seja a responsável, ela pode utilizar o sistema disponibilizado pela ANTT por meio do programa CIOT para Todos. Para que servem a DLL e o executável encontrados no programa CIOT para Todos? Não para uso rotineiro. A geração do CIOT por meio do programa CIOT para Todos deve ser feita via integração com o web service disponibilizado pela própria ANTT. A DLL e o executável são destinados exclusivamente ao uso em contingência, ou seja, situações em que a integração com o web service não está disponível. Nesses casos, eles permitem gerar o número do CIOT sem todos os dados da operação, funcionando como solução temporária. No entanto, em até 168 horas, o CIOT deverá ser regularizado pelos meios adequados, conforme o fluxograma abaixo. Existe alguma solução no ACBr para me ajudar a gerar o CIOT? Atualmente o ACBr conta com o componente desenvolvido nativamente para Delphi e Lazarus denominado ACBrCIOT, que realiza a integração com a IPEF eFrete. A integração com novas IPEFs, bem como a disponibilização do CIOT no ACBrMonitorPLUS e na ACBrLib, estão previstas em nosso planejamento para implementação futura. O programa de exemplo do componente ACBrCIOT pode ser encontrado no caminho: ..\trunk2\Exemplos\ACBrDFe\ACBrCIOT onde estão disponíveis versões tanto para Delphi quanto para Lazarus. Onde posso encontrar os manuais das IPEFs? Os manuais de cada IPEF podem ser encontrados no portal respectivo de cada uma. Além disso, nós também os centralizamos em nosso biblioteca do Tools em ...\tools\DFe\CIOT Onde devo preencher o CIOT? O CIOT deve ser informado no Manifesto Eletrônico de Documentos Fiscais (MDF-e), no elemento CIOT, que faz parte do grupo infCIOT presente nas informações da ANTT. A estrutura do XML com essa informação é semelhante a este exemplo: <rodo> <infANTT> <infCIOT> <CIOT>pseudoCIOT</CIOT> <CNPJ>pseudoCNPJ</CNPJ> </infCIOT> </infANTT> </rodo> O campo <CNPJ> ou <CPF> deve ser preenchido com a identificação do responsável pela geração do CIOT. Como preencher o CIOT no MDF-e utilizando o componente ACBrMDFe? Caso utilize componente nativo para Delphi/Lazarus, alimente as propriedades: var lMDFe: TMDFe; lRodo: Trodo; linfCIOT: TinfCIOTCollectionItem; begin lMDFe := ACBrMDFe1.Manifestos.Add.MDFe; lRodo := lMDFe.rodo; linfCIOT := lRodo.infANTT.infCIOT.New; linfCIOT.CIOT := 'pseudoCIOT'; linfCIOT.CNPJCPF := 'pseudoCNPJ'; //Demais informações... end; Caso utilize ACBrMonitorPLUS ou ACBrLibMDFe, alimente em seu arquivo INI: [infCIOT001] CNPJCPF=pseudoCNPJ CIOT=pseudoCIOT O CIOT é exibido no DAMDFe? Não! De acordo com o Manual MDFe Anexo II DAMDFE v3.00a, não há previsão de que o CIOT seja exibido no DAMDFe, portanto sua ausência não indica nenhum problema. Links Úteis e Referências RESOLUÇÃO Nº 3.658, DE 19 DE ABRIL DE 2011 RESOLUÇÃO Nº 5.862, DE 17 DE DEZEMBRO DE 2019 RESOLUÇÃO ANTT Nº 6.078, DE 24 DE MARÇO DE 2026 Lei nº 11.442 de 05 de janeiro de 2007 Perguntas Frequentes - CIOT

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

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

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

Bom dia @Diogo Loff, Por favor leia o tópico abaixo.

Bom dia Para impressão de DANFSe v2.0 em fastreport Já tem as mudanças no ACBrNFSeXDANFSeFR ?

Olá, pessoal! Apenas reportando que, em testes realizados no dia 14/07/2026 após as 15h19, o comportamento reportado na primeira postagem ainda permanece: A Sefaz ainda está autorizando o evento 211120, que deveria ter sido removido. A Sefaz ainda está autorizando o evento 211110 no leiaute antigo. A Sefaz está rejeitando o novo leiaute proposto pela NT 2025/002 v1.40, apontando estrutura de XML inválida com o elemento gCredPresOper.

Bom dia Alex, Obrigado pela observação e contribuição. A correção foi realizada. Apenas para informação estamos usando a função OnlyCPFCNPJAlphaNum para incluir a validação dos novos CNPJ alfanuméricos. At revision: 47168

Bom dia, @ANDERSSON CARLOS CANDIDO! No momento, não temos uma previsão. A tarefa está no backlog e, em breve, deve ser adicionada a alguma sprint para ser analisada.

Olá comunidade ! Foi publicada a Nota Técnica 2026/002 v1.00 que tratando das operações presenciais e não presenciais com o uso do DANFe Simplificado Tipo 2. Introdução Visando atender as determinações estabelecidas nos Ajustes SINIEF nº 32/25 e nº 13/26 essa NT contempla entre outros aspectos: O uso de NF-e em operações presenciais e não presenciais com o DANFe Simplificado Tipo 2. O uso do DANFe Simplificado Tipo 2 nas operações previstas no Ajuste SINIEF Um alerta na emissão de NFC-e quando o destinatário for identificado por CNPJ e estiver em situação irregular. Vedação de NF-e de saída que faça referência NFC-e ou CF-e, exceto na emissão de NF-e complementar. Regulamentação do uso de contingência off-line para NF-e quando DANFE Simplificado Tipo 2; Alterações Autorização de uso com alerta Esta nota técnica introduz um novo cStat para autorizar a NF-e com um alerta: Ao receber esse novo cStat, a mensagem de alerta detalhada será devolvida em campo específico adicionado junto da estrutura protNFe no XML. O objetivo dessa nova informação é alertar ao emissor de alguma inconsistência que deve ser verificada, mas que não é motivo suficiente para provocar rejeição. Por enquanto, esse novo cStat será disponibilizado apenas para NFC-e. Leiaute da NF-e/NFC-e. Adiciona no campo tpImp o novo valor "6=DANFE Simplificado Tipo 2 (nas condições do Ajuste SINIEF 13/26)." Altera a descrição do valor 4 no campo indPres para "4=Operações não presenciais com NFC-e e NFe com DANFE Simplificado Tipo 2 (com entrega);" Altera a descrição do valor 9 do campo tpEmis para "9=Contingência off-line da NFC-e e da NF-e com DANFE Simplificado Tipo 2". Regra de validação Algumas regras de validação anteriormente aplicadas somente para a NFC-e modelo 65 também passam a ser aplicadas para a NF-e modelo 55, a citar alguns exemplos: Regra que verifica data de entrada e saída Regra que verifica operação de entrada. Regra que verifica operação interestadual ou com o exterior. Altera a regra que verifica o limite máximo que permite a emissão de NFC-e sem identificação do destinatário Será criada uma tabela pela Sefaz com os valores por UF e na ausência de uma definição, mantem-se o limite de R$ 10.000,00. Cria regras de validação que verificam a necessidade e proibição da informação do local de entrega e também a correta referenciação de outros documentos na nota. Datas Alteração da regra de validação que permite a emissão da NFC-e sem a identificação do destinatário Implantação Teste: 01/06/2026 Implantação Produção: 15/06/2026 Aplicação das regras de validação para NF-e e criação da regra de validação que rejeita NF-e de saída referenciando modelo 65 e 59. Implantação Teste: 01/07/2026 Implantação Produção: 03/08/2026 Estrutura que devolve autorização com alertas e demais regras de validação. Implantação Teste: 01/09/2026 Implantação Produção: 05/10/2026 E como fica o ACBr? Modificações serão necessárias nas soluções ACBr. Para esta finalidade, foi criada a tarefa ACBR-9423. Qualquer novidade a respeito será divulgado neste tópico ou diretamente em nossa área de notícias. Leia a versão completa desta nota técnica AQUI. Um agradecimento ao membro de nossa comunidade @mateusjurado por compartilhar a informação no canal #sefaz em nossa comunidade do Discord.

Tarefa ACBR-9423 já no SVN.

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

tudo via api

Olá, comunidade ! No dia 03/07/2026 foi publicada versão 1.40 da Nota Técnica 20214/002 que trata do serviço de DistribuiçãoDFe para a nota fiscal eletrônica. Alterações Essa versão adequa o serviço ao CNPJ alfanumérico alterando todas as ocorrências desse campo do tipo numérico para o tipo caracteres permitindo agora que o valor tenha além de números, letras também. Essa versão também adiciona o literal "transportador" no título da coluna que ilustra quais são os arquivos devolvidos para o participante identificado no evento de "Ator interessado" removendo assim quaisquer ambiguidades: Datas A implantação tanto em homologação quanto em produção ocorrerá na mesma data de 08/07/2026 E como fica o ACBr? As soluções ACBr já vem sendo adequadas ao CNPJ alfanumérico e o progresso desse processo pode ser conferido no tópico abaixo: Leia a versão 1.40 desta nota técnica na íntegra AQUI.

Bom dia, Nos últimos meses homologuei NFSe em várias cidades e precisei fazer ajustes (trocas de provedores, versão ou parametros). Segue a lista de cidades com as alterações feitas para que possam atualizar no AcbrNfse: [1500602] Nome=Altamira UF=PA Provedor=PadraoNacional [2604106] Nome=Caruaru UF=PE Provedor=Giss Versao=2.04 Params=Dividir100: ProRecepcionar=https://ws-caruaru.giss.com.br/service-ws/nf/nfse-ws [2706307] Nome=Palmeira dos Indios UF=AL Provedor=Agili Params=NomeTagAtividadeEconomica:ItemLei116AtividadeEconomica|NaoGerarTag:ItemLei116 [2906709] Nome=Candido Sales UF=BA Provedor=Saatri Versao=2.03 ProRecepcionar=https://candidosales.saatri.com.br/servicos/nfse.svc HomRecepcionar=https://homologa-candidosales.saatri.com.br/servicos/nfse.svc ProLinkURL=https://candidosales.saatri.com.br/Relatorio/VisualizarNotaFiscal?numero=%NumeroNFSe%&codigoVerificacao=%CodVerif% HomLinkURL=https://homologa-candidosales.saatri.com.br/Relatorio/VisualizarNotaFiscal?numero=%NumeroNFSe%&codigoVerificacao=%CodVerif% [2913200] Nome=Ibotirama UF=BA Provedor=Saatri Versao=2.03 ProRecepcionar=https://ibotirama.saatri.com.br/servicos/nfse.svc HomRecepcionar=https://homologa-ibotirama.saatri.com.br/servicos/nfse.svc ProLinkURL=https://ibotirama.saatri.com.br/Relatorio/VisualizarNotaFiscal?numero=%NumeroNFSe%&codigoVerificacao=%CodVerif% HomLinkURL=https://ibotirama.saatri.com.br/Relatorio/VisualizarNotaFiscal?numero=%NumeroNFSe%&codigoVerificacao=%CodVerif% [2921302] Nome=Milagres UF=BA Provedor=Sudoeste Versao=2.02 ProRecepcionar=http://nfse.milagres.ba.gov.br/webrun/webservices/NFEServices.jws [2931350] Nome=Teixeira de Freitas UF=BA Provedor=Sudoeste Versao=2.02 ProRecepcionar=http://nfsewsteixeira.sistemasonline.net.br/webrun/webservices/NFEServices.jws HomRecepcionar=http://177.93.108.119:4040/nfsews/webservices/NFEServices.jws [3114402] Nome=Carmo do Rio Claro UF=MG Provedor=PadraoNacional [3117504] Nome=Conceicao do Mato Dentro UF=MG Provedor=GovDigital Versao=2.00 ProRecepcionar=https://ws.nfe-cidades.com.br/ws/cmatodentro HomRecepcionar=https://ws.homolog.nfe-cidades.com.br/ws/cmatodentro [3158953] Nome=Santana do Paraiso UF=MG Provedor=GestaoISS Versao=2.02 ProRecepcionar=https://santanadoparaisomg.gestaoiss.com.br/ws/nfse.asmx [3161106] Nome=Sao Francisco UF=MG Provedor=PadraoNacional [3201902] Nome=Domingos Martins UF=ES Provedor=EL Versao=2.04 ProRecepcionar=https://nfse-backend.domingosmartins.es.gov.br/nfse34/NfseWSService [3556453] Nome=Vargem Grande Paulista UF=SP Provedor=GovDigital Versao=2.01 Params=NaoDividir100: Params=NaoDividir100: ProRecepcionar=https://ws.nfe-cidades.com.br/ws/vgp HomRecepcionar=https://ws.homolog.nfe-cidades.com.br/ws/vgp [5218300] Nome=Posse UF=GO Provedor=Centi Versao=2.02 Params=NaoFormatarItemServico: ProRecepcionar=* ProConsultarNFSeRps=https://api.centi.com.br/nfe/consultar/rps/go/posse ProCancelarNFSe=https://api.centi.com.br/nfe/cancelar/go/posse ProGerarNFSe=https://api.centi.com.br/nfe/gerar/go/posse HomRecepcionar=* HomConsultarNFSeRps=https://api.centi.com.br/nfe/consultar/homologacao/rps/go/posse HomCancelarNFSe=https://api.centi.com.br/nfe/cancelar/homologacao/go/posse HomGerarNFSe=https://api.centi.com.br/nfe/gerar/homologacao/go/posse ProLinkURL=https://api.centi.dev.br/portal/nfse/go/posse/%ID% HomLinkURL=https://api.centi.dev.br/portal/nfse/go/posse/%ID%

Passo a passo para a integração Realize o pré-cadastrado no site Dev.eFrete. Após o preenchimento do e-mail, você vai receber um e-mail da eFrete que deve ser respondido com CNPJ da empresa e Nome fantasia do sistema, ERP ou TMS. Depois de enviar essas informações, você receberá as credências de acesso ao ambiente de homologação e os dados aceitos no ambiente. Obs: Devido ao aumento repentino no volume de integrações temos recebido relatos de que esse processo pode levar um tempo para ser concluído. Particularidades e dicas extras Operações com certificado x Login sem certificado Login sem certificado: Para qualquer operação sem o certificado digital no eFrete é preciso de um token de autenticação que é gerado ao realizar a operação de Login. A operação de Login é feita utilizando o hash, usuário, senha e não devem ser preenchidos os dados do certificado no componente, conforme exemplo: ACBrCIOT.Configuracoes.Certificados.ArquivoPFX := ''; ACBrCIOT.Configuracoes.Certificados.Senha := ''; ACBrCIOT.Configuracoes.Certificados.NumeroSerie := ''; // Atenção, desabilitar essa propriedade ACBrCIOT.SSL.UseCertificateHTTP := False; ACBrCIOT.Configuracoes.Geral.Usuario := 'usuario do eFrete'; ACBrCIOT.Configuracoes.Geral.Senha := 'senha do eFrete'; ACBrCIOT.Configuracoes.Geral.HashIntegrador := 'HashIntegrador do eFrete'; A operação de login irá gerar um token que deverá ser preenchido nas demais operações, conforme exemplo: with ACBrCIOT.Contratos.Add.CIOT do begin // Só é necessário se usar usuario e senha e não o certificado Integradora.Token := 'token recebido na operação de login'; end; Operações com certificado: Para as operações com o certificado digital no eFrete, o login não é necessário pois não será utilizado o token, bastando preencher os dados do certificado, conforme exemplo: // Não preencher o ArquivoPFX se preencher o NumeroSerie ACBrCIOT.Configuracoes.Certificados.ArquivoPFX := 'arquivo. pfx'; ACBrCIOT.Configuracoes.Certificados.Senha := 'senha do certificado'; // Não preencher o NumeroSerie se preencher o ArquivoPFX ACBrCIOT.Configuracoes.Certificados.NumeroSerie := 'número de série do certificado'; // Atenção, habilitar essa propriedade ACBrCIOT.SSL.UseCertificateHTTP := True; ACBrCIOT.Configuracoes.Geral.Usuario := ''; ACBrCIOT.Configuracoes.Geral.Senha := ''; ACBrCIOT.Configuracoes.Geral.HashIntegrador := ''; Campos de mesmo nome com valores diferentes Dada a relação com o MDF-e, alguns campos podem receber a mesma informação. É importante lembrar, no entanto, que cada documento tem seu próprio conjunto de valores aceitos. Um exemplo é o campo TipoRodado no eFrete e o campo tpRod no MDF-e. Ambos recebem a informação do tipo de rodado, mas cada documento aceita um conjunto de valores diferente: MDF-e: 01 - Truck; 02 - Toco; 03 - Cavalo Mecânico; 04 - VAN; 05 - Utilitário; 06 - Outros. eFrete: NaoAplicavel; Truck; Toco; Cavalo. Exemplo de preenchimento do tipo Rodado para o eFrete no ACBrCIOT: var lCIOT: TCIOT; begin lCIOT := ACBrCIOT.Contratos.Add.CIOT; lCIOT.Integradora.Operacao := opGravarVeiculo; //Valores válidos são trNaoAplicavel, trTruck, trToco, trCavalo lCIOT.GravarVeiculo.TipoRodado := trNaoAplicavel; //Demais informações... end; Valores e informações específicos para o ambiente de homologação O ambiente de homologação por padrão solicita o envio de um certificado digital, mas seu envio não é obrigatório. Em ambiente de homologação apenas os Integradores são cadastrados, informe seu próprio, CNPJ como MatrizCNPJ e como Contratante do Frete nas requisições relacionadas. Exemplo de preenchimento de MatrizCNPJ e Cnpj do contratente no ACBrCIOT para o eFrete: var lCIOT: TCIOT; begin lCIOT := ACBrCIOT.Contratos.Add.CIOT; lCIOT.Integradora.Operacao := opAdicionar; lCIOT.AdicionarOperacao.MatrizCNPJ := 'pseudoCNPJ'; lCIOT.AdicionarOperacao.Contratante.CpfOuCnpj := 'mesmopseudoCNPJ'; //Demais informações... end; Web Service Soap x API Rest A integradora eFrete disponibiliza tanto um web service SOAP que comunica com arquivos XMLs quanto uma API Rest que recebe arquivos JSON. O componente ACBrCIOT se comunica com o web service SOAP. Caso enfrente algum problema ou erro inesperado, é válido realizar um teste para a mesma operação na API Rest e conferir se o retorno diverge. Você pode utilizar uma ferramenta de IA para converter o XML gerado pelo componente no JSON correspondente e fazer o envio. Leia o manual do eFrete na integra AQUI.

Olá, bom dia! Conferi na Planilha do leiaute de Padrão Nacional "RN DPS - RTC_IBSCBS"... certo, não há tags de alíquotas e valores. De acordo com essa definição e aplicação em leiaute, subentende-se que neste ano teste 2026 as tags de DPS não levarão grupo/tags referente a alíquotas e valores pois estão definidas fixas (IBS 0,1% & CBS 0,9%). Levantando um questionamento, não encontrei material sobre... A partir de 2027, quando as alíquotas serão alteradas e ajustadas conforme novas definições e poderão ser diferentes entre Estados e/ou Municípios (se tratando de IBS) poderão ser implementadas novas tags de alíquotas e valores a serem configurados pelos usuários em seus sistemas, ou se manterão fixos de acordo com as localidades preenchidos/calculados pelo XML de retorno/aprovação?

Olá Pessoal, Com a Reforma Tributária temos novas opções de emissão de NF-e, vamos tentar entender como funciona essa tal de nota de Débito ou Crédito. Na Nota Técnica 2025/002 versão 1.20 no final da página 7 temos o item 4 que traz: 4. Finalidade Débito e Finalidade Crédito da NF-e Notas de Débito e Crédito são nomes de instrumentos utilizados mundialmente para documentar situações contábeis onde é necessário corrigir informações comerciais que foram registradas em um documento, que no Brasil é a Nota Fiscal. Esta Nota Técnica cria na NF-e modelo 55 as finalidades de emissões correspondentes. O sentido das palavras “débito” e “crédito” sempre se referem ao ponto de vista do emissor: • Uma nota de débito documenta uma situação na qual o emitente registra um aumento no imposto devido (consequentemente, uma redução no imposto devido pelo adquirente, que é o destinatário); • Uma nota de crédito documenta uma situação na qual o emitente registra uma redução no imposto devido (consequentemente, um aumento no imposto devido pelo adquirente, que é o destinatário); As finalidades de emissão “Nota de Ajuste” e “Nota Complementar”, já existentes, são casos especiais de Nota de Débito; uma nota de entrada emitida para documentar, por exemplo, a devolução de mercadoria que havia sido vendida a um consumidor final, é um caso especial de Nota de Crédito. A regulamentação do IBS disporá sobre a utilização de notas de crédito e notas de débito para lançamentos de ajuste, com a finalidade de instrumentalizar a preparação da declaração assistida a ser oferecida para os contribuintes, de maneira automatizada, a partir de documentos fiscais eletrônicos, em cumprimento ao que preconiza a LC 214/2025. A menos que ocorra alteração na regulamentação do ICMS e do IPI, notas de crédito e notas de débito não poderão ser utilizadas para ajustes relativos a estes tributos. O campo finNFe agora passa a ter as opções: 5=Nota de crédito; 6=Nota de débito; Portanto se a minha intenção é emitir uma NF-e de Crédito o valor de finNFe tem que ser 5, por outro lado se a intenção é emitir uma NF-e de Débito o valor de finNFe tem que ser 6. Temos agora que especificar o tipo da nota de Débito ou de Crédito através dos novos campos tpNFDebito e tpNFCredito. Devemos ter em mente que uma nota só pode ser de Débito ou de Crédito jamais vai ser de Débito e Crédito. Valores aceitos pelo campo tpNFDebito: 01=Transferência de créditos para Cooperativas; 02=Anulação de Crédito por Saídas Imunes/Isentas; 03=Débitos de notas fiscais não processadas na apuração; 04=Multa e juros; 05=Transferência de crédito de sucessão; 06 = Pagamento antecipado 07 = Perda em estoque Valores aceitos pelo campo tpNFCredito: 01 = Multa e juros 02 = Apropriação de crédito presumido de IBS sobre o saldo devedor na ZFM (art. 450, § 1º, LC 214/25) 03 = Retorno (regra de validação: B25-80) Uma nota de Débito ou Crédito não podem conter informações de: ICMS (tag: ICMS), ISSQN (tag: ISSQN), IPI (tag: IPI), II (tag: II), PIS (tag: PIS), PIS ST (tag: PISST), COFINS (tag: COFINS), COFINS ST (tag: COFINSST), ICMS UF Destino (tag: ICMSUFDest) ou Imposto Devolvido (tag: impostoDevol). Uma NFC-e (modelo 65) não permite nota de Débito ou Crédito, esses dois tipos de notas estão restritas ao modelo 55 ou seja NF-e. (regra de validação: UB106-31) Temos um novo gruo chamado gTransfCred que só deve ser gerado se a de nota de Débito tiver o tpNFDebito for 01 ou 05. O grupo gTransfCred só deve ser gerado se o CST / cClassTrib informado o permitir. (regra de validação: VC02-10) Se tpNFDebito for 03 ou 04 devemos gerar o novo grupo DFeReferenciado. (regra de validação: 3BA02-70) Uma nota de crédito de multa/juros, tpNFCredito igual a 01 ou 03 tem que referenciar uma NF-e autorizada e não pode estar cancelada. (regra de validação: B25-30) Se tpNFCredito for 01 ou 03 devemos gerar o novo grupo DFeReferenciado. A nota de Débito ou Crédito não é simples, possui muitas regras de validação, vai ser natural levarmos uma rejeição logo na primeira nota, mas de posse da NT em mãos para buscar um entendimento sobre a rejeição e sanar o problema vai ser o caminho. Tudo é muito novo para nós desenvolvedores e para os contadores, o jeito vai ser dar as mãos e tentarmos buscar a melhor implementação. Não sou contador, sou desenvolver, mas busco sempre as respostas nos Manuais, Notas Técnicas e longas conversas com os contadores. Espero que esse texto possa ajudar um pouco com esses dois tipos de notas.

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.