Painel de líderes

Olá Pessoal, Boas novas, as etapas 2 e 3 já foram concluídas para todos os componentes e já se encontram no SVN. Partiu etapa 4 que visa adequar os métodos de leitura e escrita do arquivo INI, como dito anteriormente usados pelo ACBrMonitor e ACBrLib. Quando esta etapa for finalizada vou trabalhar nos programas exemplos. Não fiquem apavorados em querer alterar as suas aplicações, pois vocês não vão conseguir realizarem testes em ambiente de homologação da SEFAZ uma vez que este ambiente só vai ser liberado em 01/09/2025 isso se não for prorrogado. Todas as implementações estão sendo realizadas com base nas Notas Técnicas: 2024/001 e 2024/002 ambas versão 1.10 pode ser que surge uma nova versão e com isso tenhamos que alterar algumas coisas na implementação. Por fim e não menos importante, mantenham os fontes do ACBr atualizados e instalados.

Olá Pessoal, Muitos de vocês estão ansiosos e apreensivos com essa mudança que vai ocorrer. Os componentes do ACBr vão ser afetados com essa reforma? Sim, mas fiquem tranquilos que já estamos trabalhando nas modificações. Como que fica a minha aplicação, também vai ser afetada? Sim, e te aconselho conversar com os contadores dos seus clientes para saber o que vai ser necessário calcular e como calcular. Como esta os trabalhos e quais são os componentes que vão ser afetados? Dividimos o trabalho em 5 etapas e os componentes afetados são: ACBrBPe (Bilhete de Passagem Eletrônico/Bilhete de Passagem Eletrônico Metropolitano); ACBrCTe (Conhecimento de Transporte Eletrônico/Conhecimento de Transporte Simplificado Eletrônico/Conhecimento de Transporte Outros Serviços); ACBrNF3e (Nota Fiscal de Energia Elétrica Eletrônica); ACBrNFCom (Nota Fiscal de Comunicação Eletrônica); ACBrNFe (Nota Fiscal Eletrônica/Nota Fiscal ao Consumidor Eletrônica) e ACBrNFSeX (Nota Fiscal de Serviço Eletrônica). Etapas definidas para a implementação da Reforma Tributária nos componentes: 1. Alteração nas classes para criar os grupos e seus respectivos campos; 2. Alteração na unit responsável pela escrita do XML; 3. Alteração na unit responsável pela leitura do XML; 4. Alteração nas funções de escrita e leitura do arquivo INI (utilizado pelo ACBrMonitor e ACBLib). 5. Alteração nos programas exemplos Delphi/Lazarus visando mostrar como alimentar o componente referente aos novos campos dos novos grupos. Observações: A primeira etapa já foi concluída para todos os componentes exceto ACBrNFe. No caso do ACBrNFSeX a implementação contempla somente a NFS-e Padrão Nacional (provedor PadraoNacional), não sabemos como vai ficar o layout do XML do RPS dos provedores que tem layout próprio ou utilizam a versão 1 ou 2 do layout da ABRASF. No que se refere a NF-e/NFC-e além das alterações necessárias para contemplar a reforma tributária, vai ser necessário também implementar 12 novos eventos que vamos discriminar em postagem futura. Prazos: Segundo a NT/2024/001 versão 1.10 - Reforma Tributária - IBS e CBS (BPe, CTe, NF3e e NFCom) e a NT/2024/002 versão 1.10 - Reforma Tributária - IBS e CBS (NFe e NFCe) traz as seguintes datas: Ambiente de Homologação: 01/09/2025 Ambiente de Produção: 31/10/2025 Já a Nota Técnica 001 - SE-CGNFSe - Novo Layout - RTC (NFSe) temos a data de janeiro/2026 como sendo o inicio do novo layout, infelizmente não informa se é ambiente de homologação ou produção. Assim que finalizarmos a primeira etapa no componente ACBrNFe, avisaremos neste tópico o inicio da segunda etapa.

Olá Pessoal, Algumas units do componente ACBrNFe foram reescritas e se encontram em outra pasta com um novo nome, portanto as anteriores deixaram de serem utilizadas pelo componente e consequentemente estão sendo removidas do SVN. Units em desuso que estão sendo removidas estavam na pasta ...Fontes\ACBrDFe\ACBrNFe\PCNNFe, são elas: pcnAdmCSCNFCe, pcnConsSitNFe, pcnEnvEventoNFe, pcnEventoNFe, pcnInutNFe, pcnRetAdmCSCNFCe, pcnRetConsSitNFe, pcnRetEnvEventoNFe e pcnRetInutNFe. As novas units que o componente esta utilizando se encontram na pasta ...\Fontes\ACBrDFe\ACBrNFe\Base\Servicos, são elas: ACBrNFe.AdmCSC, ACBrNFe.ConsSit, ACBrNFe.EnvEvento, ACBrNFe.EventoClass, ACBrNFe.Inut, ACBrNFe.RetAdmCSC, ACBrNFe.RetConsSit, ACBrNFe.RetEnvEvento e ACBrNFe.RetInut. Caso você tenha informado em "uses" uma das units que foram removidas você deve trocar o nome dela pela sua equivalente, conforme a relação: pcnAdmCSCNFCe deve ser substituída por ACBrNFe.AdmCSC pcnConsSitNFe deve ser substituída por ACBrNFe.ConsSit pcnEnvEventoNFe deve ser substituída por ACBrNFe.EnvEvento pcnEventoNFe deve ser substituída por ACBrNFe.EventoClass pcnInutNFe deve ser substitúida por ACBrNFe.Inut pcnRetAdmCSCNFCe deve ser substituída por ACBrNFe.RetAdmCSC pcnRetConsSitNFe deve ser substituída por ACBrNFe.RetConsSit pcnRetEnvEventoNFe deve ser substituída por ACBrNFe.RetEnvEvento pcnRetInutNFe deve ser substituída por ACBrNFe.RetInut

Olá Pessoal, É com muita alegria que eu informo a vocês que os trabalhos para adequar os componentes perante a Reforma Tributária esta a todo vapor. Já foi finalizado os ajustes nos componentes: ACBrCTe, ACBrNF3e e ACBrNFCom. Os fontes alterados bem como os Schemas e os programas exemplos dos 3 componentes mencionados acima já estão no SVN. Quero lembrar que ainda não é possível enviar o XML contendo os novos campos para a SEFAZ, uma vez que esta ainda não liberou o ambiente de homologação que esta previsto para 01/07/2025. Até o final deste mês vamos finalizar e enviar para o SVN os ajustes nos componentes: ACBrBPe, ACBrNFe e ACBrNFSeX. No caso da NFe ainda não foi disponibilizado os Schemas. Já a NFSe além da falta dos Schemas e alteração se concentra no layout do Padrão Nacional. Não sabemos qual a atitude dos provedores que utilizam a versa 1 ou 2 do layout da ABRASF bem como os que tem o seu próprio layout. Até a próxima pessoal.

Olá pessoal! Nos últimos dias temos recebidos diversos relatos de membros de nossa comunidade com problemas para realizar o processo de Manifestação do Destinatário, seja realizando o envio de evento ou a consulta de DistribuicaoDFe. Todos os relatos tinham em comum o fato de estarem conseguindo consumir os webservices de transmissão da NF-e normalmente, mas estarem recebendo as mensagens: Erro Interno: -2146893815 Erro HTTP: 0 URL: https://www.nfe.fazenda.gov.br/NFeRecepcaoEvento4/NFeRecepcaoEvento4.asmx Erro: 2148073481 Ou: Erro: WebService Distribuição DFe: - Inativo ou inoperante tente novamente. Erro interno: -2146893815 Erro HTTP: 0 URL: https://www1.nfe.fazenda.gov.br/NFeDistribuicaoDFe/NFeDistribuicaoDFe.asmx Erro: 2148073481 - Em casos assim, é sempre válido abrir um Fale Conosco junto ao fisco para que o mesmo fique ciente de que há algo errado. Abaixo reproduzido na íntegra temos a resposta que foi fornecida pelo membro de nossa comunidade @Jhonathan na qual ele demonstra um passo a passo que executou para resolver um erro semelhante que havia enfrentado anteriormente com NFC-e e que também de acordo com múltiplos relatos de colegas da comunidade resolveu o problema agora com a manifestação do destinatário: 1- Vá até o Painel de Controle do Windows. 2- Escolha a Opção "Opções da Internet"; 3- Vá até a aba “Avançadas”; 4- No bloco “Configurações”, vá até as últimas opções e deixe configurado como na imagem abaixo: 5- Vá em executar, digite certlm.msc para abrir a interface de certificados, caso esse comando não funcione, utilize o comando certmgr.msc. Remova estes certificados listados na imagem abaixo: 6- Execute como Administrador o InstaladorCadeias_1.0.2.0.exe, clique em Instalar e aguarde até que o processo seja finalizado. 7- Execute o FixCrypto_TLS1_2_Windows.reg. 8- Descompacte o CA.zip e execute o ac soluti ssl ev.cer e o Raiz-icp-brasil v10.cer. 9- Reinicie a máquina e teste novamente a comunicação com a Sefaz.

Coordenação Técnica do ENCAT 16/06/2025 Consulta Tabelas CST, cClass e Credito Presumido para Reforma Tributária As notas técnicas que preveem a criação da estrutura de dados para alimentar a tributação relativa à Reforma Tributária do Consumo estão publicadas no portal e já existem prazos para a implantação desta versão no ambiente de homologação até do dia 28 de julho de 2025 para NFe, NFCe, BPe, CTe, NF3e e NFCom. Todas as Notas Técnicas apresentam regras de validação que fazem referências as tabelas de CST, Classificação Tributária e Crédito Presumido e seus indicadores (flags) que obrigam ou vedam o preenchimento dos diversos grupos de informações no XML do Documento Fiscal. Visando faciliar o entendimento da aplicação prática destas regras de validação, e sobretudo, trazer dados mais concretos de que forma os ambientes de autorização dos documentos fiscais trabalharão as validações, estamos publicando na forma de consulta deste portal o acesso visual a estas tabelas. Tabelas de CST e cClass: https://dfe-portal.svrs.rs.gov.br/DFE/TabelaClassificacaoTributaria Tabela de Crédito Presumido: https://dfe-portal.svrs.rs.gov.br/DFE/TabelaCreditoPresumido IMPORTANTE: O trabalho de levantamento de situações, aderência à legislação e prospecção de regras de validação, assim como a própria composição destas tabelas é um trabalho em constante revisão e aprimoramento, o que pode resultar em modificações nestas informações. Uma vantagem importante é que a estas tabelas estão acessando o motor de validação em banco de dados, o mesmo que o sistema de autorização da SVRS estará utilizando. Qualquer alteração nas tabelas refletirá imediatamente nas consultas do portal e na validação das regras dos documentos fiscais eletrônicos.

Muitos usuários estão recebendo notificações dos bancos, sobre o fator de vencimento dos boletos vai ser reiniciado: Fique tranquilo que já está pronta esta implementação: Você não precisa configurar nada, esta implementação já foi feita pelo nosso querido @BigWings em 2015 conforme post abaixo:

Olá pessoal! É com muita alegria que informamos a adição de mais um componente no pacote ACBrBaas, o ACBrPagamentosAPI! O que é o pacote ACBrBaas? O pacote ACBr Banking As Service (Baas para abreviar) visa unir componentes que consomem serviços variados disponibilizados pelas APIs bancárias. O que é o componente ACBrPagamentosAPI? Este componente visa realizar a integração junto as APIs disponibilizadas pelos bancos para permitir realizar pagamentos de forma integrada. Seguindo a mesma lógica do ACBrPagFor que gera arquivos via CNAB. Onde encontro o componente? Os fontes podem ser encontrados em ..\trunk2\Fontes\ACBrBaaS Os programas de exemplo podem ser encontrados em ..\trunk2\Exemplos\ACBrBaaS\ACBrPagamentosAPI Um agradecimento ao consultor @EliasCesar pelo desenvolvimento do componente e pela empresa Poliview Sistemas na qual atua o consultor @Renato Rubinho por financiar o desenvolvimento do componente. Bancos implementados até o momento:

Olá pessoal! No dia 01/08/2024 foi publicada a Nota Técnica 2024/002 que traz as alterações referentes a NF-e/NFC-e visando adequar este documento as modificações propostas pela reforma tributária. Introdução O Projeto de Lei Complementar PLP 68 estabelece que os estados, o distrito federal e os municípios devem adequar seus sistemas autorizadores para permitir a informação dos dados relacionados ao Imposto sobre Bens e Serviços (IBS), Contribuição sobre Bens e Serviços (CBS) e Imposto Seletivo (IS). Esta nota técnica trata da adequação do layout da Nota Fiscal Eletrônica (modelo 55) e da Nota Fiscal de Consumidor Eletrônica (modelo 65). Os demais documentos serão tratados na NT 2024/001: Alterações Tipos Básicos da Tributação Os campos acrescidos no layout que serão tratados mais a frente constam no arquivo DFeTiposBasicos_v1.00.xsd, adicionado ao pacote de esquemas dos documentos fiscais, junto a esta nota técnica. Código Situação Tributária e Código de Classificação da Tributação Serão disponibilizadas no portal da nacional da nota fiscal eletrônica, tabelas que relacionam o CST e cClassTrib que devem ser utilizados no preenchimento do documento fiscal eletrônico. Finalidades débito e crédito da NF-e 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 "Nota de Ajuste" e "Nota Complementar" que já existem são casos especiais de "Nota de Débito". Já uma "Nota de Entada" emitida para documentar, por exemplo, a devolução de mercadoria que havia sido vendida para consumidor final é uma caso especial de "Nota de Crédito". Alterações no Layout Foi adicionado então, no campo que documenta a Finalidade de emissão da NF-e (finNFe) os valores 5 e 6 que respectivamente correspondem a Nota de crédito e Nota de débito. A cardinalidade do grupo ICMS passou a ser 0-1, dando a possibilidade do campo ser opcional. Adiciona o grupo IBSCBSSel para receber as Informações do Bens e Serviços - IBS, Contribuição de Bens e Serviços - CBS e Imposto Seletivo.. O grupo conta com um elemento para receber o Código de Situação Tributária do Imposto Seletivo (CST), o Código de Classificação Tributária do Imposto Seletivo (cClassTrib) além de um grupo para as informações dos impostos propriamente ditas e um para as informações dos impostos em operações com impostos monofásicos, ambos contendo seus próprios subgrupos e adicionando uma quantidade expressiva de novos campos. Adiciona grupo IBSCBSSelTot para totalizar as informações dos Imposto de Bens e Serviços IBS, Contribuição de Bens e Serviços CBS e Imposto Seletivo IS. O novo grupo totalizadores poderá ter até 22 novos campos que serão utilizados para totalizar as informações da NF-e/NFC-e dos elementos informados no grupo mencionado acima. Regras de Validação Esta nota técnica adiciona novas regras de validação que dentre outras coisa verificam: Se a finalidade de débito ou crédito for utilizada com grupo de impostos diferente de IBS/CBS. Se a finalidade diferente de débito ou crédito for utilizada sem o grupo de ICMS ou ISSQN. Se foi informado Imposto Seletivo para uma classificação que não o permite. Se não foi informado Imposto Seletivo para uma classificação que o obriga. Se foi informado CST ou cClassTrib inexistente. Se as informações do grupo IBS/CBS foram preenchidas corretamente. Se os totalizadores do IBS/CBS estão corretos. Eventos Esta nota técnica também conceitua os seguintes novos eventos: Decurso de Prazo de Internalização na Área de Livre Comércio - ALC ou Zona Franca de Manaus - ZFM: Evento e seu respectivo cancelamento. Solicitação de Apropriação de Crédito Presumido e seu respectivo cancelamento. Destinação de Item para Consumo Pessoal e seu respectivo cancelamento. Imobilização de Item e seu respectivo cancelamento. Solicitação de Apropriação de Crédito de Combustível e seu respectivo cancelamento. Datas Implantação Teste: 01/09/2025 Implantação Produção: 31/10/2025 Vale ressaltar que como as discussões referentes a reforma tributária ainda estão em curso, a NT pode ser ajustada ao longo do processo. E como fica o ACBr? Serão necessários ajustes nos fontes do ACBr e novas compilações do Monitor e da Lib. Foi criada a #TK-5816 em nosso backlog para alteração dos fontes. Vale ressaltar que a NT é recente e existe um período expressivo até que seja liberada a homologação. Leita a NT na integra AQUI

Olá Pessoal, Boas novas, o componente ACBrNFe já esta pronto para gerar o QR-Code na versão 3.00 que é utilizado na NFC-e. Essa nova versão esta documentada na Nota Técnica 2025/001 que além da versão 3.00 do QR-Code também temos a resposta síncrona para lote com somente 1 (uma) nota. Com relação ao modo de envio síncrono já faz um bom tempo que o componente dispõe dessa funcionalidade, na verdade desde julho/2013. Lembrando que o envio em modo síncrono esta condicionado a somente uma nota por lote, ou seja, envio unitário. Vale também ressaltar que hoje podemos realizar um envio unitário em modo assíncrono, mas em breve não vai mais ser possível, somente no modo síncrono. Tanto a versão 3.00 do QR-Code quanto a obrigatoriedade do modo síncrono para o envio unitário de NF-e segue o seguinte cronograma: Ambiente de homologação 02/06/2025 e produção 01/09/2025. Mantenham os fontes do ACBr atualizados e reinstalados. Fiquem atentos aos Papos Pro que são realizados todas as terças e quintas no Discord.

Pessoal, A etapa 1 que visa implementar nas classes os novos grupos e campos, foi totalmente implementada em todos os componentes mencionados na postagem anterior. Vamos agora partir para a etapa 2.

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

Aqui pra mim estava dando o mesmo erro com Windows 11 no cliente e na minha maquina com o certificado A3, e consegui resolver da seguinte forma: 1- Vá até o Painel de Controle do Windows. 2- Escolha a Opção "Opções da Internet"; 3- Vá até a aba “Avançadas”; 4- No bloco “Configurações”, vá até as últimas opções e deixe configurado como na imagem abaixo: 5- Vá em executar, digite certlm.msc para abrir a interface de certificados, caso esse comando não funcione, utilize o comando certmgr.msc. Remova estes certificados listados na imagem abaixo: 6- Execute como Administrador o InstaladorCadeias_1.0.2.0.exe, clique em Instalar e aguarde até que o processo seja finalizado. 7- Execute o FixCrypto_TLS1_2_Windows.reg. 8- Descompacte o CA.zip e execute o ac soluti ssl ev.cer e o Raiz-icp-brasil v10.cer. 9- Reinicie a máquina e teste novamente a comunicação com a Sefaz.

Olá pessoal, Informamos que propriedade dos componentes responsável por salvar o arquivo XML -procEventoNFe.xml em disco foi alterada! Entendendo melhor... Os componentes possuem algumas propriedade de configuração destinadas a determinar se os XMLs gerados devem ser salvos em disco ou não, são elas: Configuracoes.Arquivos.Salvar -> Determina se os XMLs dos Documentos Fiscais devem ser salvos (Por padrão o valor da propriedade é True). Configuracoes.Arquivos.SalvarEvento -> Determina se os XMLs de Processamento de Eventos devem ser salvos (Por padrão o valor da propriedade é False). Configuracoes.Geral.Salvar -> Determina se os XMLs auxiliares, ou seja, XML de envio e de retorno do webservice devem ser salvos (Por padrão o valor da propriedade é True). Configuracoes.WebServices.Salvar -> Determina se os XMLs auxiliares, ou seja, XML de envio e de retorno do webservice exatamente como são enviados e retornados sem nenhum tratamento devem ser salvos (Por padrão o valor da propriedade é False). Notem que existe uma propriedade de configuração especifica para eventos, sendo assim achamos por bem mudar a condição que determina se o XML de Processamento de Evento vai ser salvo em disco ou não. Antes era usado como condição a propriedade Configuracoes.Arquivos.Salvar e agora vai ser utilizada a propriedade Configuracoes.Arquivos.SalvarEvento. Como mostrado acima a propriedade SalvarEvento tem como valor padrão False, sendo assim se faz necessário alterar o seu valor via código ou no Object Inspector caso o desenvolvedor queira que o XML de Processamento do Evento seja salvo em disco. A motivação dessa mudança é utilizar a propriedade de configuração correta para a situação em questão que é determinar se o XML de Processamento do Evento deve ser salvo em disco ou não.

Olá pessoal! No dia 01/07/2024, alguns membros de nossa comunidade começaram a relatar que ao tentar emitir uma NF-e ou NFC-e estão recebendo a rejeição: Está rejeição foi introduzida na Nota Técnica 2023/001 em sua versão 1.00, no entanto, a mesma foi removida logo na versão 1.10 permanecendo assim até a sua versão 1.51 que é a mais atual. Hoje, dia 01/07/2024, está entrando em vigor no ambiente de produção a Nota Técnica 2023/004 que coincidentemente adiciona a seguinte rejeição: PORTANTO, se você está recebendo a rejeição 963 com a mensagem de Alíquota adrem, verifique se informou no tPag da respectiva nota valor diferente de 03, 04, 10, 11, 12, 13, 15, 17 e 18 e adicionou o grupo card. Se o fez, remova o grupo card, conforme Regra de Validação da própria rejeição: Aprovada a nota, também é muito importante que abram um Fale Conosco junto a respectiva Sefaz, relatando que a mensagem que está sendo devolvida está incorreta.

Olá Pessoal, Se encontra disponível desde 21/05/2025 a unit ACBrDFe.Conversao. Essa unit contem os tipos, enumerados e as funções de conversão utilizados pela Reforma Tributária. Sendo assim na unit da sua aplicação que se utiliza dos enumerados e das funções se faz necessário declarar a unit ACBrDFe.Conversao no uses.

Olá Pessoal, Vamos atualizar esse tópico. Já foi finalizado os ajustes nos componentes: ACBrBPe, ACBrCTe, ACBrNF3e e ACBrNFCom. Os fontes alterados bem como os Schemas e os programas exemplos dos 4 componentes mencionados acima já estão no SVN. Quero lembrar que ainda não é possível enviar o XML contendo os novos campos para a SEFAZ, uma vez que esta ainda não liberou o ambiente de homologação que esta previsto para 01/07/2025. Até o final deste mês (abril) vamos finalizar e enviar para o SVN os ajustes no componente: ACBrNFe. Os Schemas da NFe já foram disponibilizados, assim que enviarmos para o SVN os fontes do componente, enviaremos também os schemas e o programa exemplo. Deixamos o componente ACBrNFSeX para o final pois não temos os Schemas para realizar os testes e lembrando que alteração se concentra no layout do Padrão Nacional. Não sabemos qual a atitude dos provedores que utilizam a versa 1 ou 2 do layout da ABRASF bem como os que tem o seu próprio layout. Até a próxima pessoal.

Olá pessoal! Este tópico tem o objetivo de centralizar as informações disponíveis sobre a Reforma Tributária para facilitar e ajudar aqueles que estão buscando mais conhecimentos sobre o assunto para se preparar. Notas Técnicas 2025 Nota técnica com as modificações específicas para NF-e\NFC-e: Nota técnica com as modificações específicas para BP-e: Nota técnica com as modificações específicas para NF3e: Nota técnica com as modificações específicas para NFCom: Nota técnica com as modificações específicas para o CTe/CTeOS/GTVe: 2024 Nota técnica com as modificações específicas para NF-e\NFC-e: Nota técnica com as modificações específicas para CT-e\CTe-OS\BP-e\NF3-e\NFCom: Nota Técnica com as modificações específicas para NFS-e: FAQ Modificações no ACBr Edições do Papo PRO ACBr (mais recentes primeiro) 2025 2024 Tópicos da Comunidade discutindo sobre o assunto.

Não, você não leu errado o título da notícia. A sefaz de São Paulo está dando adeus ao SAT! Foi publicado no dia 31/10/2024 a Portaria SRE 79, DE 31 DE OUTUBRO DE 2024 que modifica a Portaria CAT147/12(responsável pela definição do SAT), acrescentando na mesma os seguintes artigos: Efetivamente impedindo a ativação de novos equipamentos SAT para quem ainda não o tinha o aparelho e estipulando a data de 01/01/2026 para o fim do SAT como um todo. Mas se eu uso o SAT o que eu vou fazer agora? A NFC-e é o documento fiscal que deverá ser utilizado no lugar do CF-e. A muito tempo, esses documentos são "intercambiáveis", com o contribuinte podendo escolher se emite uma NFC-e ou um CF-e através do SAT para acobertar a mesma operação. Eu estou um pouquinho enferrujado, mas o SAT não era a contingência da NFC-e? Não mais! A Sefaz já havia publicado previamente uma portaria autorizando o uso da contingência off-line para NFC-e no estado. Veja mais aqui:

Olá Pessoal, Novidades sobre o CNPJ alfanumérico. Senhores Representantes, bom dia! A Coordenação-Geral de Gestão de Cadastros e Benefícios Fiscais - Cocad, por meio do documento anexo, oficializa os senhores sobre a alteração da Instrução Normativa RFB n° 2119/2022, que passa a dispor sobre o CNPJ Alfanumérico, a ser implementado em Julho de 2026. Ademais, informa-se que por meio dos links abaixo, podem os senhores terem acesso a documentos e informações elucidativas e informativas adicionais. https://www.gov.br/receitafederal/pt-br/acesso-a-informacao/acoes-e-programas/programas-e-atividades/cnpj-alfanumerico https://www.gov.br/fazenda/pt-br/assuntos/noticias/2024/outubro/receita-federal-anuncia-que-cnpj-tera-letras-e-numeros-a-partir-de-julho-de-2026 Ats. Michelle Campos Sales Silvério Dicaj - Divisão de Cadastro de Pessoas Jurídicas Oficio-Circular-RFB-Cocad n 87-2024.pdf

Olá Pessoal, É com grande prazer que comunico o envio ao SVN do componente para impressão do DANFCom em Fortes Report bem com o DAEventos em papel A4. No momento se faz necessário a instalação do componente via os pacotes disponíveis. Em breve o ACBrInstall será atualizado visando a instalação do componente. Ainda falta pequenos ajustes na impressão do DANFCom, mas ele já esta funcional.

Bom dia, Problema identificado. Drive de CH340, do conversor USBxRS232. O driver mais recente de 2023, que é o instalado automaticamente pelo windows 11, apresenta o problema relatado acima. Solucionamos utilizando um driver CH340 instalável, versão de 2019, através de um executável. Vou disponibilizar no link abaixo, caso mais alguém esteja com problemas neste conversor. DRIVER CH340

Olá, pessoal. Temos o prazer de anunciar que o novo pacote ACBrBaas já está disponível no SVN! Este pacote foi criado para facilitar a integração de sistemas com serviços bancários e APIs de pagamento, atendendo à crescente demanda por soluções de automação financeira. ACBrExtratoAPI: Primeira Solução Disponível O primeiro componente disponível neste pacote é o ACBrExtratoAPI. Este componente permite a consulta de transações do extrato de uma conta corrente, ideal para quem precisa automatizar o acompanhamento e controle financeiro diretamente em seu software. Atualmente, o ACBrExtratoAPI oferece suporte para dois bancos: Banco do Brasil Banco Inter A proposta é expandir o suporte para outros bancos, conforme a demanda dos usuários. Então, caso seu banco de interesse ainda não esteja incluído, fique à vontade para sugerir a inclusão! Futuros Componentes no Pacote ACBrBaas Além do ACBrExtratoAPI, estamos trabalhando na inclusão de novos componentes ao pacote ACBrBaas, que irão ampliar ainda mais suas funcionalidades, entre eles: ACBrPagamentosAPI: Voltado para a integração com APIs de pagamento, facilitando transações financeiras diretamente pelo software. ACBrBBPay: Um componente específico para a plataforma BBPay, do Banco do Brasil, que permitirá realizar transações de forma simplificada. Estamos atentos às necessidades dos usuários e planejamos adicionar mais APIs bancárias e de pagamento, tornando o ACBrBaas uma ferramenta essencial para desenvolvedores que buscam eficiência e automação no setor financeiro. Disponível em: https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrBaaS/ Fiquem atentos às próximas atualizações!

Olá pessoal! Foi publicado o AJUSTE SINIEF Nº 2, DE 11 DE ABRIL DE 2025 que aumenta o prazo em que o fisco deve guardar os documentos fiscais eletrônicos emitidos. Em outras palavras, agora o fisco deve guardar o XML da NF-e, CT-e, MDF-e, NFC-e, BP-e, NF3e, CTe-OS, GTV-e, DC-e, NFCom e todos os seus eventos vinculados por um período de 11 anos. O ajuste entra em vigor na data de sua publicação e produz efeitos a partir do primeiro dia do mês subsequente. Vale mencionar: O prazo de guarda desses documentos pelos contribuintes permanece inalterado conforme artigo 174 da Lei N° 5.172, de Outubro de 1996: Em outras palavras, a Sefaz precisa guardar os XMLs por 11 anos e o contribuinte precisa guardar o XML por 5 anos.

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

Olá comunidade ACBr, No passar dos anos alguns bancos sofreram mudanças de marcas, conhecido como Rebranding, como foi o caso por exemplo do Bancoob que se transformou em Sicoob entre outros. Não vamos descontinuar as classes ou configurações em que o componente ACBrBoleto foi criado nos bancos em questão, porem, foi criado um "helper" para os usuários que possam sentir dificuldades para localizar esses bancos que no decorrer dos anos sofreram mudanças de marca. No momento as classes são: Enumerador Novos Enumerador Original cobBancoSicoob cobBancoob cobBancoSisprime cobUniprimeNortePR cobBancoAilos cobBancoCECRED Esses novos enumeradores só é válido para parametrização da Classe, seja para CNAB ou Webservices. Exemplo : na utilização do enumerador cobBancoSicoob ou cobBancoob a classe iniciada será a TACBrBancoob; OBS: Na utilização da Função GetTipoCobranca, o Tipo de Cobrança retornado será o Enumerador Original, usando o mesmo exemplo acima no caso do banco 756 será retornado cobBancoob

Olá Pessoal, Vamos atualizar esse tópico. Já foi finalizado os ajustes nos componentes: ACBrBPe, ACBrCTe, ACBrNF3e, ACBrNFCom e ACBrNFe. Os fontes alterados bem como os Schemas e os programas exemplos dos 5 componentes mencionados acima já estão no SVN. Quero lembrar que ainda não é possível enviar o XML contendo os novos campos para a SEFAZ, uma vez que esta ainda não liberou o ambiente de homologação que esta previsto para 01/07/2025. Estamos trabalhando já no componente ACBrNFSeX, mas como dito anteriormente até a postagem desse tópico não foi publicado os Schemas. No que se refere a NFSe temos duas questões: 1. A NT publicada com as mudanças no layout referente a Reforma Tributária é no layout da NFS-e Padrão Nacional (não confundir com ABRASF). 2. Hoje o componente ACBrNFSeX atende 1848 cidades, algumas delas contrataram provedores que usam a versão 1 do layout da ABRASF, outras contrataram provedores que usam a versão 2 do layout da ABRASF e outras contrataram provedores que tem layout próprio. Não sabemos qual a atitude dos provedores que utilizam a versão 1 ou 2 do layout da ABRASF bem como os que tem o seu próprio layout no que se refere a Reforma Tributária. Eles vão alterar o layout que usam para adequar a Reforma ou vão abandonar o layout em uso e vão passar a usar o layout da NFS-e Padrão Nacional? Não temos a resposta para essa pergunta. Até a próxima pessoal.

Olá pessoal! É com grande alegria que informamos que foi disponibilizada a impressão de eventos para NFC-e com o FPDF A nova impressão possui leiaute semelhante ao print(informações de identificação foram censuradas): Vale lembrar para aqueles que usam componente nativo, que para o correto funcionamento da mesma, é necessário que o XML da NFC-e correspondente seja carregado na memória previamente. Quem utiliza ACBrMonitor ou ACBrLib já é requisitado como parâmetro do comando ImprimirEventoPDF que seja passado o XML da NFC-e. Versões da ACBrLib compiladas depois das 11h50 do dia 02/04/2025 deverão englobar o ajuste. Um agradecimento ao @Arimateia Jr pelo auxílio ao fornecer a base para a implementação.

Olá pessoal! É com grande alegria que informamos a vocês que uma novidade muito pedida pelos membros da comunidade, os dockers do ACBr, são agora uma realidade! O primeiro docker disponível foi construído para demonstrar o uso dos exemplos de consumo da Lib disponíveis para a linguagem PHP(mais sobre eles AQUI). O fonte pode ser encontrado neste repositório do nosso perfil oficial do GitHub e a imagem pode ser encontrada neste repositório em nosso perfil oficial no DockerHub. Além do docker em PHP que foi disponibilizado, outros estão em construção para demonstrar o uso em outras linguagens! O que é Docker e para que ele serve? O docker é um container que pode isolar as configurações e dependências necessárias para o correto funcionamento de uma aplicação, garantindo facilidade de implantação, portabilidade, consistência e escalabilidade. Posso usar o Docker do ACBr em produção? O docker foi construído para demonstrar e orientar como criar um container da maneira certa para o correto uso das soluções do ACBr, portanto, recomendamos o estudo do container para criarem suas imagens de acordo com as necessidades e particularidades de sua aplicação, mas não recomendamos o uso do docker do ACBr direto em produção. Ouça mais informações sobre os Dockers do ACBr nesta edição do Papo PRO que foi realizada sobre o assunto:

Olá Pessoal, Para quem não esta sabendo temos um novo documento fiscal eletrônico chamado DC-e - Declaração de Conteúdo Eletrônica. Já temos o componente ACBrDCe e já se encontra na lista de componentes a serem instalados pelo ACBrInstall. Até o momento somente o ambiente de homologação que esta disponível, o ambiente de produção esta prometido para 2025. Hoje (26/09/2024) realizei diversos testes e fiz algumas correções no código do componente. Resultado dos testes: 1. Envio do DC-e para a SEFAZ, funcionando e caso os dados estejam corretos é retornado o protocolo de autorização; 2. Consulta ao status de serviço, funcionando; 3. Consulta o DC-e pela chave, funcionando; 4. Envio do pedido de Cancelamento (único evento disponível), funcionando e caso os dados estejam corretos é retornado o protocolo de autorização; 5. Impressão do DACE, funcionando; 6. Impressão do Evento, funcionando. Convido a todos a atualizar todos os fontes de todas as pastas, reinstale o ACBr e inicie os testes usando o programa exemplo. Caso encontre algum erro, por favor crie um tópico no fórum expondo o erro e se possível a solução.

Olá Pessoal, Já se encontra no SVN a atualização dos fontes de componente ACBrCTe visando a emissão do CT-e Simplificado. Foi enviando também a atualização dos programas exemplos tanto em Delphi quanto em Lazarus, que agora tem uma procedure para exemplificar a alimentação do componente para a emissão do CT-e Simplificado. Peço a todos que façam a atualização dos fontes, reinstale o ACBr e realizem os testes. Até a data de hoje (17/09/2024) somente a SEFAZ-Virtual do RS que disponibilizou as URLs de homologação especificas para o CT-e Simplificado, sendo assim somente RS e as UF atendidas pela SVRS que vão poder realizar os testes neste momento. UF atendidas pela SVRS: AC, AL, AM, BA, CE, DF, ES, GO, MA,PA, PB, PI, RJ, RN, RO, RS, SC, SE e TO. Caso encontre algum erro na emissão do CT-e Simplificado ou no CT-e ou CT-e OS ou GTV-e, por favor criem um tópico no fórum relatando o problema para que possamos sanar o mais breve possível.

Olá Pessoal, Algumas units do componente ACBrCTe foram reescritas e se encontram em outra pasta com um novo nome, portanto as anteriores deixaram de serem utilizadas pelo componente e consequentemente estão sendo removidas do SVN. Units em desuso que estão sendo removidas estavam na pasta ...Fontes\ACBrDFe\ACBrCTe\PCNCTe, são elas: pcteConsSitCTe, pcteRetConsSitCTe, pcteEventoCTe, pcteEnvEventoCTe, pcteRetEnvEventoCTe, pcteLayoutTXT e pcteModeloCTe. As novas units que o componente esta utilizando se encontram na pasta ...\Fontes\ACBrDFe\ACBrCTe\Base\Servicos, são elas: ACBrCTe.ConsSit, ACBrCTe.RetConsSit, ACBrCTe.EventoClass, ACBrCTe.EnvEvento e ACBrCTe.RetEnvEvento. Caso você tenha informado em "uses" uma das units que foram removidas você deve trocar o nome dela pela sua equivalente, conforme relação: pcteConsSitCTe deve ser substituída por ACBrCTe.ConsSit pcteRetConsSitCTe deve ser substituída por ACBrCTe.RetConsSit pcteEventoCTe deve ser substituída por ACBrCTe.EventoClass pcteEnvEventoCTe deve ser substituída por ACBrCTe.EnvEvento pcteRetEnvEventoCTe deve ser substituída por ACBrCTe.RetEnvEvento

Olá pessoal, No nosso objetivo de sempre melhorar o código do ACBr deixá-lo mais organizado e legível, estamos fazendo algumas mudanças e achamos importantes expô-las para todos. Detectamos alguns tipos que não estão sendo mais usados por nenhum componente ou classe no código do ACBr e por isso, achamos melhor remover. Além disso, parte do que estamos fazendo no momento é migrando definições de classes e tipos e também algumas funções da unit "pcnConversao.pas" para units mais especializadas como a "pcnConversaoNFe.pas". No caso dessas funções e classes/tipos, elas não são utilizadas fora de um "componente" específico. Assim, reduzimos o escopo. Também estamos, na medida do possível, criando novas versões de funções que convertem tipos enumerados (StrToXXXX ou XXXXToStr), removendo o parâmetro "ok". Isso já acontece em muitas funções do mesmo tipo em outras áreas do projeto. Muitas vezes esse parâmetro "ok" é ignorado pelos programadores e essa situação pode causar problemas difíceis de serem diagnosticados. Não queremos incentivar esse comportamento... Abaixo uma lista dos tipos migrados e para qual unit ele foi destinado. As funções relacionadas a esses tipos foram migradas também para a unit mencionada: TpcnSituacaoEmissor - Descontinuado e removido - Não é utilizado em nenhum componente. TpcnIndicadorEmissor - Descontinuado e removido - Não é utilizado em nenhum componente. TpcnIndicadorContinuacao - Descontinuado e removido - Não é utilizado em nenhum componente. TpcnSituacaoManifDest - Descontinuado e removido - Não é utilizado em nenhum componente. TpcnFormatoGravacao - Movido para unit pcnGerador TDetFormato - Movido para unit ACBrDFeReport TpcteModeloNF - Movido para unit pcnConversaoCTe TpcnIndicadorPagamento - Movido para unit pcnConversaoNFe TpcnPercentualTributos - Movido para unit pcnConversaoNFe TpcnDeterminacaoBaseIcms = Movido para unit pcnConversaoNFe TpcnDeterminacaoBaseIcmsST = Movido para unit pcnConversaoNFe TpcnMotivoDesoneracaoICMS = Movido para unit pcnConversaoNFe TpcnCstIpi - Movido para unit pcnConversaoNFe TpcnIndicadorProcesso - Movido para unit pcnConversaoNFe TpcnCRT - Movido para unit pcnConversaoNFe TpcnIndicadorTotal - Movido para unit pcnConversaoNFe TpcnECFModRef - Movido para unit pcnConversaoNFe TpcnISSQNcSitTrib - Movido para unit pcnConversaoNFe TpcnImprimeDescAcrescItem - Movido para unit pcnConversaoNFe TpcnDestinoOperacao - Movido para unit pcnConversaoNFe TpcnConsumidorFinal - Movido para unit pcnConversaoNFe TpcnPresencaComprador - Movido para unit pcnConversaoNFe TpcnFormaPagamento - Movido para unit pcnConversaoNFe TpcnBandeiraCartao - Movido para unit pcnConversaoNFe TpcnTipoViaTransp - Movido para unit pcnConversaoNFe TpcnTipoIntermedio- Movido para unit pcnConversaoNFe TpcnindISSRet - Movido para unit pcnConversaoNFe TpcnindISS - Movido para unit pcnConversaoNFe TpcnTipoAutor - Movido para unit pcnConversaoNFe As primeiras alterações foram enviadas ao SVN na revisão 34752. Bom trabalho pessoal.

Olá Pessoal, Foi publicado ontem (28/03/2025) Notas Técnicas especificas para cada modelo de Documento Fiscal Eletrônico referente a Reforma Tributária. Notas Técnicas publicadas para o BP-e, CT-e, NF3-e e NF-e/NFC-e, esta faltando a publicação da NT referente a NFCom. Em uma leitura rápida não ocorreu grandes alterações. Somente a NF-e/NFC-e que trazia um grupo referente a Compras Governamentais, este grupo agora esta presente nos demais DF-e. Outro ponto a se destacar é quanto aos prazos de liberação dos ambientes de homologação e produção. Ambiente de homologação que antes estava previsto para 01/09/2025 passou para 01/07/2025. E o ambiente de produção estava previsto para 31/10/225 passou para 01/10/2025. Com essa alteração de datas os desenvolvedores passaram a ter 3 meses em vez de 2 para adequar suas aplicações e fazerem os testes. No que se refere a NFS-e também foi publicado uma nova NT que traz algumas modificações no layout sendo que uma delas é a inclusão do grupo de Compras Governamentais. Infelizmente essa NT não traz datas de inicio do ambiente de homologação (produção restrita como eles chamam) e do ambiente de produção. A única informação que consta é que em janeiro/2026 as NFS-e devem já atender a reforma tributária, ou seja, já deve constar os novos grupos e campos. Com essas novas modificações nos layouts dos DF-e vamos ter que rever tudo o que foi feito e fazer as alterações necessárias. Pessoal, agora mais do que nunca devemos manter os fontes do ACBr atualizados e reinstalados se possível diariamente. Vamos fazer novos Papo Pro no Discord relatando as mudanças e em qual etapa estamos na adequação dos componentes. Não percam os Papo Pro eles são de extrema importância para que vocês fiquem informados.

Olá Pessoal, Algumas units foram substituídas por outras com outros nomes mas com o mesmo conteúdo. Para quem emite CT-e/CT-e Simplificado/CT-e OS/GTV-e e por ventura faça uso em sua aplicação da unit pcteCTe deverá mudar o nome dela para ACBrCTe.Classes que se encontra na pasta: ...\Fontes\ACBrDFe\ACBrCTe\Base. Para quem emite MDF-e e por ventura faça uso em sua aplicação da unit pmdfeMDFe deverá mudar o nome dela para ACBrMDFe.Classes que se encontra na pasta: ...\Fontes\ACBrDFe\ACBrMDFe\Base. Para quem emite NF-e/NFC-e e por ventura faça uso em sua aplicação da unit pcnNFe deverá mudar o nome dela para ACBrNFe.Classes que se encontra na pasta: ...\Fontes\ACBrDFe\ACBrNFe\Base. Observação: Façam as trocas listadas acima, pois em breve as units "antigas" vão ser removidas do SVN. Novas substituições vão ocorrer, fiquem atentos e mantenham os fontes do ACBr atualizados. Após a atualização caso tenha algum problema vai ai uma dica: Você tem fontes do ACBr com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build. Por fim repita os testes.

Estamos animados em anunciar que estamos trabalhando na implementação do suporte ao Bradesco por meio de Webservices. Essa novidade trará maior agilidade e eficiência nas integrações com o banco, ampliando as possibilidades de automação e facilitando o dia a dia dos nossos usuários. No entanto, para que possamos concluir esta implementação e garantir a funcionalidade completa, precisamos da colaboração da comunidade. Estamos em busca de credenciais de homologação do Bradesco para realizar testes e ajustes finais. Se você tiver acesso a essas credenciais e certificado digital de homologação e puder nos ajudar, pedimos que entre em contato via e-mail com as credenciais [email protected] . Toda ajuda será valiosa para acelerar o processo de homologação e assegurar que todos possam desfrutar dos benefícios dessa integração. Agradecemos antecipadamente a todos que possam contribuir e ajudar a fortalecer nossa comunidade!

Olá comunidade ACBr, O componente ACBrBoleto, agora oferece a emissão e consulta detalhada de boletos via Web Service (WS / API) do Banco Cora 403. Essa atualização traz mais praticidade e eficiência para a gestão financeira, permitindo uma integração mais rápida e precisa nas transações bancárias. para configurar o banco utilizar : [Componente Emissão WebServices] Banco.TipoCobranca := cobBancoCora; Configuracoes.WebService.ClientID: Cedente.CNPJCPF := 'xxxxxxxxxxxxxx'; informar o cnpj do emitente, pois compõe o nosso numero Titulo.Carteira := '01'; Titulo.SeuNumero := X; subtituir o X pelo controle interno da empresa, deve ser um código unico a cada boleto Titulo.NossoNumero := 0; enviar o valor 0, pois é o banco em que numera, somente informar qualquer valor na impressão / reimpressão //Serviços disponíveis Configuracoes.WebService.Operacao: (tpInclui, tpConsultaDetalhe, tpCancelar ou tpBaixa) Agradecimentos no apoio nos testes e implementação pelas credenciais ao usuário @luisclaudio_jr

Olá pessoal! Desde a ativação no ambiente de produção das regras de validação da Nota Técnica 2023/004, alguns membros de nossa comunidade tem relatado estar recebendo a rejeição: Essa rejeição é devolvida quando é informado na nota o tipo de pagamento Cartão de Crédito (tPag=03), Cartão de Débito (tPag=04) ou Pagamento Instantâneo (PIX) - Dinâmico (tPag=17) e não é informado o grupo card. Conforme regra de validação da própria rejeição: Considerando os múltiplos relatos em diferentes Sefaz e o fato de a implementação da regra ser opcional a critério da UF. Nossos colegas da AFRAC buscaram mais informações, entrando em contato com as Sefaz de PB, PE, MG e RJ questionando sobre a ativação desta regra em específico, obtendo as seguintes respostas: Sefaz de MG: “Vamos retornar à regra anterior, ou seja, sem ativar a validação em questão, portanto, apenas para cartão. Para isso, teremos que subir uma versão da aplicação. Enquanto isso, a opção é usarem o código 20 ao invés do 17." Sefaz da PB: “Quem informava o código 17 para Pix estático deve informar o código 20. Iremos publicar no site oficial da Sefaz ainda hoje (01/07) após às 17h." Portanto, para evitar a rejeição, o Pix deverá ser informado no código 20 e, assim, evitar o preenchimento do código de autorização desse formato de pagamento. Em tempo, irão realizar pedido à SVRS para desativar temporariamente a regra de validação Y04-10 para o estado da Paraíba. A expectativa é que a SVRS faça isso até amanhã pela manhã (02/07), portanto, no momento, a solução é informar o código 20 no Pix para não obrigar a informar o grupo de cartões, onde terá que informar o E2dID Sefaz de PE: Aguardando resposta. Sefaz do RJ: "Isso ocorreu porque as empresas estavam acostumadas a informar o código 17 para o PIX. Agora elas devem informar o código 20 se for PIX estático. Se continuarem a informar o código 17 é o PIX dinâmico e a regra de validação exige informar o grupo card, pelo menos o código de autorização do PIX (endToEndId - e2eid ). A AFRAC encaminhou pedido de reavaliação para desativação dessa regra de validação nas UF´s que não disciplinaram a interligação dos pagamentos tal como realizado no RS e MT." Este tópico foi feito baseado em comunicado publicado no Radar AFRAC e que pode ser encontrado na íntegra AQUI.

Olá pessoal! Se você não sabe do que se trata as classes baseadas em ACBrXMLDocument, o tópico abaixo tem mais detalhes: Mas em um resumo: São classes criadas de forma a utilizar as vantagens da LibXML para leitura e escrita dos arquivos XML. Elas são mais rápidas do que as classes baseadas na PCN. Elas foram criadas com o objetivo de substituir a PCN. Como podem ver no tópico indicado acima, desde antes de dezembro de 2024 essas novas classes já estão disponíveis e podem ser utilizadas pela comunidade através de opção no instalador. Agora, 6 meses depois, decidimos que a essas classes serão adotadas como padrão pelo ACBr, ou seja, ao invés de a opção vir desmarcada no instalador, ela vira selecionada por default. Por que estamos realizando esta mudança? Como é mencionado no tópico, consideramos que elas trazem vantagens em comparação com as classes da PCN. Depois de um período de 6 meses, com a comunidade já podendo utilizar elas e sem relatos recentes de problemas, consideramos que elas já estão maduras o suficiente para serem adotadas como padrão. Com o advento da Reforma Tributária, fica inviável manter a manutenção tanto nas classes PCN quanto nas classes ACBrXMLDocument, portanto, os novos campos relacionados a reforma foram adicionadas somente nas novas classes. Quais impactos essa mudança pode gerar? Como mencionado, essas novas classes precisam da LibXML para o correto funcionamento, portanto as dlls devem ser devidamente distribuídas junto ao executável ou estarem presentes no Path. Se você utiliza as units em sua aplicação, é provável que precise realizar a troca para evitar problemas de escopo. Por exemplo, substituir na seção uses da sua aplicação, onde tiver pcnNFeW por ACBrNFe.XmlWriter e onde tiver pcnNFeR por ACBrNFe.XmlReader.

Olá Pessoal, É com grande alegria que informo a todos que o componente ACBrNFe já esta em conformidade com a NT 2025/002 versão 1.01 referente a Reforma Tributária. Já se encontra no SVN os fontes, os Schemas e o programa exemplo em Delphi que exemplifica como alimentar os novos campos. Quero deixar bem claro que o ambiente de homologação só vai estar liberado em 01/07/2025 para recepcionar os XML com os novos campos referente a Reforma Tributária. Portanto nem adianta tentar enviar que o XML vai ser rejeitado.

Olá Pessoal, O componente ACBrANe passou por um Refactoring. A motivação para esse Refactoring é tornar o componente mais fácil e prático no que se refere a implementar novas seguradoras bem como realizar manutenção no código sem correr o risco de gerar um efeito colateral nas seguradoras já implementadas. Antes tínhamos apenas uma unit responsável por gerar o arquivo de envio para todas as seguradoras. Isso gerava riscos na implementação e manutenção das seguradoras existentes. Agora temos uma unit para cada seguradora que gera o arquivo. Assim, podemos fazer as devidas melhorias bem como as correções sem afetar as outras seguradoras. Pasta dos fontes: Outro ponto importante é a localização das Units que compõe o componente: Pasta Descrição ACBrANe Pasta raiz dos fontes do componente. Seguradoras Pasta que contem as units das seguradoras: (NomeSeguradora.Provider). Base Pasta que contem as units de classes, conversão e constantes. Base\Seguradoras Pasta que contem as units bases e manager. Base\WebServices Pasta que contem as units base e response do webservice Situação atual: Hoje o componente já conta com as seguintes seguradoras implementadas: ATM e ELT. Até tem a PortoSeguro, mas não esta funcional, se faz necessário finalizar a sua implementação. Desafios a frente: Implementar e testar novas seguradoras. Para que isso ocorra, contamos com a colaboração de todos.

Olá pessoal! No dia 10/07/2024 foi publicado pela Sefaz de São Paulo a Portaria SRE 40 de Julho de 2024. A nova portaria dispõe sobre a emissão da nota fiscal de consumidor eletrônico - NFC-e, seu respectivo documento auxiliar, o credenciamento dos contribuintes e outras providências. A principal novidade trazida por esta portaria é a redação do artigo 6º, cujo conteúdo segue abaixo na íntegra: Em suma, o referido texto, significa que agora é permitido realizar a emissão de NFC-e para o estado de São Paulo, fazendo uso da contingência off-line. Já conhecida e utilizada para este documento em outras UFs emissoras. Um agradecimento ao membro de nossa comunidade @marcopoloviana por compartilhar a informação em nosso Discord. Vale lembrar que os membros ACBr PRO tem acesso ao curso Implementando a Contingência Off-line, onde o modelo de contingência é explicado e demonstrado na prática.

Olá pessoal! No dia 25/03/2025 foi publicada a versão 1.00 da NT2025/001. Alterações NFC-e: Leiaute QR-Code versão 3 O controle da autenticidade do conteúdo do QR-Code impresso no DANFE NFC-e para notas emitidas em contingência será feito por meio da assinatura de campos específicos do QR-Code e a inclusão do resultado da assinatura no mesmo. Neste novo modelo não será mais necessário controlar o Código de Segurança do Contribuinte(CSC), com previsão de eliminação dos mesmos(ainda sem data definida). NFC-e para Produtor Rural - Pessoa Física Em várias UFs é concecida uma Inscrição Estadual para os produtores rurais utilizarem com CPF. Isso gerava certa complexidade operacional para gerenciar os CSCs. Por causa disso, a orientação agora é que seja utilizado o novo leiaute QR-Code (versão 3) para o produtor rural pessoa física(exceto no PR). Para pessoa jurídica é permitida a escolha entre a versão 2 ou 3. Resposta Síncrona para Lote com somente 1 (uma) NF-e O envio de Lotes de NF-e que contenham apenas uma nota, agora deve ser feito de maneira síncrona. Controle do Atraso na Data de Emissão da NF-e A data de emissão da NF-e que anteriormente aceitava um atraso de 30 dias da data atual, agora aceitará um atraso de apenas 7. Regras de validação Desativa a regra de validação GAP03a-2 que devolvida cStat 776 e Rejeição: Solicitada resposta síncrona para UF que não disponibiliza este atendimento, substituindo a mesma pela GAP03a-3 que devolve cStat 452 e Rejeição: Solicitada resposta assíncrona para Lote com somente 1 (uma) NF-e. Altera a regra de validação que devolve cStat 228 e Rejeição Data de Emissão muito atrasada para que valide um prazo de 7 dias independente do tipo da emissão. Altera regras para validar o campo Identificador da IE do Destinatário (indIEDest). Adiciona regras de validação para verificar se foi informado dados de cobrança para pagamento a vista ou data de vencimento superior a dez anos. Torna obrigatórias algumas regras de validação antes facultativas que verificavam a presença e também validavam os dados detalhando o pagamento no grupo que recebe os dados do cartão (card) na NF-e/NFC-e. Adiciona regras de validação específicas para versão 3 do QR-Code. Datas Implantação Teste: Até 02/06/2025 Implantação Produção: Até 01/09/2025 E como fica o ACBr? Foi criada em nosso backlog a #TK-6814 para adequação dos fontes do ACBr para versão 3.0 do QR-Code. Qualquer novidade será divulgada neste tópico. Leia a Nota Técnica 2025/001 na íntegra AQUI. Leia a versão 6.0 das especificações técnicas do DANFE NFC-e QR Code AQUI.

Olá pessoal! Como sabem, os fontes do ACBr estão passando por um processo de migração, onde as units da pcn estão sendo substituídas pelas units baseadas nas classes ACBrXMLDocument que fazem uso da LibXML2 O tópico intitulado "ATENÇÃO: ACBr está adotando as classes baseadas em ACBrXMLDocument como padrão!" traz uma explicação mais detalhada, vinculando inclusive uma edição do Papo PRO ACBr que foi realizada tratando sobre a migração. Mas resumindo em poucas palavras, as novas classes trazem um ganho de performance considerável na leitura de arquivos XML que possuem um conteúdo muito extenso, o que de acordo com o leiaute de alguns DFes é uma possibilidade. Um exemplo bem simples é a NFe\NFCe que permite até 990 itens. Este processo está sendo feito por etapas: A primeira etapa foi a mudança das classes de escrita e leitura do arquivo XML, esta etapa foi concluída. A segunda etapa é a troca de algumas units da pcn, por units próprias do ACBr, esta etapa também foi concluída. Estamos entrando agora na próxima etapa que é a mudança dos tipos. Esta etapa envolve a mudança dos tipos TpcnXXX para os tipos TACBrXXXX O processo foi iniciado no MDFe com a alteração do TpcnTipoAmbiente presente na unit pcnConversao para TACBrTipoAmbiente presente na ACBrXmlBase. Acompanhe este tópico para ficar para se manter informado sobre esta mudança. Componentes de Documentos Fiscais Eletrônicos que serão afetados: ACBrBPe ACBrMDFe (Em processo de alteração) ACBrNFe ACBrCTe ACBrDCe ACBrGNRe ACBrGTIN ACBrNF3e ACBrNFCom

Você pode achar as DLLs da LibXML2, no SVN do ACBr... https://svn.code.sf.net/p/acbr/code/trunk2/DLLs/LibXml2/ Lembrando... use a versão x86, se você compila seu .EXE em 32 bits... (independente do Windows ser 64 bits) Copie todas as DLLs do link acima, na mesma pasta do seu .EXE O quanto a implementação usando a LibXML2 é mais rápida que as antigas Units do PCN ? Confira nesse vídeo:

Olá Pessoal, Na última sexta (04/04/25) foi enviado ao svn um commit relativo a mudança no comportamento da propriedade ID, a qual deixou de trazer o prefixo do DFe (NFe, CTe, etc...) a qual a mesma se referia. Porém, hoje (08/04/25) após uma nova analise destes impactos, foi decidido reverter a alteração e retomar o comportamento anterior da propriedade. Sendo assim, aqueles que perceberam a mudança e haviam alterado suas aplicações para se adequar a mudança, devem também desfazer as alterações. Se você não percebeu a alteração pedimos que verifique seu código. Pedimos desculpas pelo transtorno e nos colocamos a disposição para quaisquer dúvidas. Justificativa A alteração acima citada foi enviada visando as adequações futuras relativas a mudança do padrão dos CNPJ. Porém, percebemos que os impactos causados não foram bem medidos. Assim, revertemos para o comportamento anterior e as alterações serão analisadas em momento futuro. At.

Olá pessoal! É com grande alegria que informamos que foram disponibilizadas versões da ACBrLib sem dependência de ambientes gráficos! Como assim dependência de ambiente gráfico? As Libs do ACBr faziam uso de um motor de relatório que adicionava dependências ao ambiente gráfico, por isso, para o correto funcionamento das mesmas, era necessário o uso de emuladores como o xvfb. Isso causava alguns transtornos e podia gerar certas dores de cabeça devido a problemas com esses emuladores. Por causa disso, foi criada uma nova versão console da Lib que faz uso exclusivamente do FPDF, removendo assim essas dependências e a necessidade do xvfb. Como faço o download das Libs Console? Quando você clica para realizar o download de uma biblioteca, serão exibidas as opções de acordo com a plataforma que deseja utilizar a mesma. A versão Console está disponível para Linux. Uma vez que o dowload tenha sido concluído, basta utilizar os .so encontrados neste caminho.

Olá Pessoal, Quando iniciamos os testes com o Provedor Giss descobrimos que ao informar o código do pais deveríamos informar 0076 em vez de 1058. O código 1058 se refere ao código IBGE do Brasil e o código 0076? Pois bem, descobri que o Provedor Giss em vez de usar o código IGBE dos países em seu webservice, acabou adotando o código ISO. Resumindo o código 0076 é o código ISO do Brasil. Foi implementando duas novas funções de conversão, uma para converter o código IBGE para ISO e a outra que converte de ISO para IBGE. A orientação abaixo é para somente quem usa o provedor Giss: Se você esta informando o código 0076 ao campo CodigoPais, deve alterar para 1058, pois o componente vai realizar a troca, caso contrario o seu RPS vai ser rejeitado, acusando que o código do pais esta errado. O objetivo dessa mudança é manter um padrão para todos os provedores ao alimentar o componente, informando sempre o código IBGE do pais e caso o provedor se utiliza de outro código como é o caso do Giss que usa o código ISO o componente se responsabiliza por realizar a conversão.

Olá pessoal, Ficamos felizes em anunciar que foram disponibilizados os programas de exemplo em PHP, Singlethread e Multithread utilizando a ACBrLibNFSe na Rev-35661. ..\ACBr\Projetos\ACBrLib\Demos\PHP\NFSe\ACBrNFSeDemoST.php ..\ACBr\Projetos\ACBrLib\Demos\PHP\NFSe\ACBrNFSeDemoMT.php Lembrando que o programa de exemplo utiliza a ACBrComum.php, contendo métodos em comum entre os modos (ST e MT) e para todas as libs. ..\ACBr\Projetos\ACBrLib\Demos\PHP\ACBrComum\ACBrComum.php Esperamos que esse novo programa de exemplo facilite a integração da comunidade PHP com as nossas bibliotecas. Até mais!!!

Olá pessoal, Queremos informar a todos nossa ciência de um problema recente no fórum que faz com que alguns tópicos fiquem inacessíveis. Você talvez veja uma mensagem semelhante a essa: Estamos cientes do problema e já solicitamos ajuda do "fabricante" para resolver. Durante esse período, alguns plugins estarão desabilitados. Assim que tivermos novidades, avisamos a todos.