Painel de líderes

Olá, Comunidade ACBr ! Com o objetivo de facilitar a integração da ACBrLibExtratoAPI para desenvolvedores que utilizam a linguagem Python , gostaríamos de anunciar a disponibilização de um programa de exemplo. Este demo ilustra a forma de realizar a comunicação com a DLL/SO da ACBrLib utilizando o módulo nativo do Python para chamadas de função em bibliotecas dinâmicas. Utilize a biblioteca versão 64 Bits MT (Multithread) ! Lembrando que estas credenciais q esta no exemplo e no print são exemplos, não são validas. Você precisa criar suas credenciais o portal do desenvolvedor. O exemplo pode ser baixado diretamente pelo repositório SVN do projeto, no caminho de Demos da ACBrLib: https://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/Python/ExtratoAPI/ Este exemplo é fundamental para quem deseja consumir os serviços de extratos bancários via API utilizando a biblioteca ExtratoAPI, e serve como base para implementação em projetos mais complexos. Aqui esta o link do manual ACBrLibExtrato API: https://acbr.sourceforge.io/ACBrLib/ACBrLibExtratoAPI.html

Muito obrigado @Italo Giurizzato Junior Já atualizei os fontes e devo iniciar os testes amanhã.

Olá comunidade ! Foi publicado o Decreto Nº 49.127 de 14 Novembro de 2025 no estado de Minas Gerais determinando a obrigatoriedade do credenciamento das empresas desenvolvedoras do software de emissão de NFe e NFCe junto a Secretaria Estadual da Fazenda (SEF). O decreto também menciona que a obrigatoriedade da informação do Responsável Técnico na emissão de NFe e NFCe será definida em portaria posterior. É importante ressaltar que apesar dessa publicação, ainda não foi disponibilizado link para que as software houses possam realizar o cadastro. Até o momento foi publicado apenas a portaria determinando a obrigatoriedade, mas é esperado que uma normativa detalhando o processo e os prazos seja publicada posteriormente. Vale relembrar que os membros de nossa comunidade que são ACBr PRO e ACBr Corporativo tem acesso ao curso: Responsável Técnico na NFe. Onde o conceito de responsável técnico é explicado e a forma de preencher essa informação nas soluções ACBr é demonstrada na prática.

Cidade/UF: Bauru/SP Previsão de Mudança: 1º de janeiro de 2026 Tipo de Mudança: API própria (manterá provedor SIL Tecnologia) Fonte/Documentação: AnexoIV-LeiautesRN_ADN-SNNFSe_V1.00.02-Produção.xlsx — Portal da Nota Fiscal de Serviço eletrônica Os Códigos de Tributação Nacional (arquivo em anexo). Os links para testes de envio das NFS-e via WebService para o ambiente de Homologação (ambiente de testes): https://homologacao.siltecnologia.com.br/tbbauru/services/WSInterface Foi elaborado um manual no formato de perguntas e respostas para auxiliar na configuração do webservice, que pode ser encontrado no link: https://interface.siltecnologia.com.br/notafiscalnacional/ Abaixo segue o Comunicado Oficial: PREFEITURA MUNICIPAL DE BAURU SECRETARIA MUNICIPAL DA FAZENDA NOTA FISCAL DE SERVIÇOS PADRÃO NACIONAL - WEBSERVICE A partir de 01/01/2026 todas as pessoas físicas e jurídicas prestadoras de serviços sujeitas à incidência do Imposto Sobre Serviços de Qualquer Natureza – ISSQN neste Município deverão emitir a Nota Fiscal de Serviços Eletrônica (NFS-e) nos moldes do padrão nacional. O município de Bauru manterá o emissor próprio de Notas Fiscais, ou seja, as empresas estabelecidas neste município continuarão a emitir as NFS-e através do sistema municipal, inclusive aquelas cuja forma de emissão se dá via WebService. Para os contribuintes que utilizam o Webservice serão realizadas alterações de tela (interface) e layout para possibilitar a integração com o padrão nacional, conforme a documentação técnica constante no link AnexoIV-LeiautesRN_ADN-SNNFSe_V1.00.02-Produção.xlsx — Portal da Nota Fiscal de Serviço eletrônica. O layout de emissão será alterado para incorporar os novos campos relacionados ao IBS e à CBS. Já os códigos de atividade de serviço seguirão o Código de Tributação Nacional. Serão compostos por 6 (seis) dígitos, resultado da combinação entre os itens e subitens da Lei Complementar nº 116, de 31 de julho de 2003, acrescidos dos desdobramentos nacionais definidos no padrão da NFS-e Nacional. Com a adoção dos Códigos de Tributação Nacional, somente será possível a emissão da Nota Fiscal de Serviços Eletrônica (NFS-e) mediante a utilização de códigos de serviço com 6 (seis) dígitos. Os Códigos de Tributação Nacional podem ser verificados no arquivo do link https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/documentacao-atual/anexo_b-nbs2-lista_servico_nacional-snnfse.xlsx/@@download/file – na aba "LISTA.SERV.NAC". Os links para testes de envio das NFS-e via WebService para o ambiente de Homologação (ambiente de testes) estão em https://homologacao.siltecnologia.com.br/tbbauru/services/WSInterface. Foi elaborado um manual no formato de perguntas e respostas para auxiliar na configuração do webservice, que pode ser encontrado no link https://interface.siltecnologia.com.br/notafiscalnacional/ Em caso de dúvidas, entrar em contato com o seguinte e-mail: [email protected] Bauru, 27 de novembro de 2025 Prefeitura Municipal de Bauru Secretaria Municipal da Fazenda ANEXO_B-NBS2-LISTA_SERVICO_NACIONAL-SNNFSe.xlsx Foi feita alterações no componente visando usar a nova API do provedor.

Boa tarde! Essa informação mudou em 27/11/2025. Bauru vai aderir ao novo padrão também. Vou postar conforme orientado pelo @Diego Foliene

Olá comunidade ! Foi publicado a versão 1.30 do Informe Técnico 2025/002 divulgando alterações nas tabelas de CST e cClassTrib utilizadas pela Reforma Tributária. Alterações Tabela de Código de Classificação Tributária do IBS e da CBS Remove a coluna EC que continha a emenda constitucional onde a situação do cClassTrib era prevista. Adiciona uma coluna Link com a URL do artigo correspondente da Lei Complementar 214/25. Tabela CST Adiciona uma coluna ind_RedutorBC para indicar se haverá redução da base de cálculo no respectivo DFe. Leita a versão 1.30 deste informe técnico completa AQUI.

Olá comunidade ! Foi publicada a versão 1.32 desta nota técnica. Alterações Esta versão não traz modificações de leiaute, ela faz correções em algumas regras de validação. A regra de validação que veda NFCe para operação não presencial vai considerar o indPres 5 para ser aplicada. A validação que verifica se a chave de nota referenciada existe não será aplicada para notas de crédito com tipo 01 e 03. A rejeição devolvida quando há ausência do grupo de ICMS para UF de destino não será aplicada para notas cujo tipo da operação governamental for 2. Datas Implantação Teste: Até 01/12/2025 Implantação Produção: 04/12/2025 E como fica o ACBr? Modificações nas soluções do ACBr não são necessárias. Leia a versão 1.32 desta nota técnica na íntegra AQUI.

Hoje, não vejo muita necessidade disso, a menos que você pretenda mostrar isso por usuário posteriormente.

Olhei aqui conferir os métodos estão tudo igual ao que você passou. protected static final int STR_BUFFER_LEN = 256; Mas faz o teste usando o ambiente Linux. Outro detalhe, o problema só ocorre quando é cancelamento no layout Nacional, quando e no provedor não ocorre o problema.

Boa tarde, Tópico movido para área aberta visando permitir maior participação da comunidade. At.

@Borante refiz o teste na versão mais nova (ACBrLibNFSe-Windows-2.0.1.213, MT Cdecl.) e o comportamento segue o mesmo: A mensagem vem completa: acbrNFSe.enviarEvento_2.0.1.213.log Estou tentando o método acbrNFSe.enviarEvento no ACBrLibNFSeMT.Demo no Windows. Vou testar no Linux também para conferir. Me confirma se ocorre o mesmo problema em seu ambiente ao rodar diretamente o Demo e chamar o método EnviarEvento. Por lá temos a implementação que lida com o tamanho do Buffer caso não seja suficiente, assim evitando que o retorno seja cortado: enviarEvento(arquivo.ini) public String enviarEvento(String aInfEvento) throws Exception { ByteBuffer buffer = ByteBuffer.allocate(STR_BUFFER_LEN); IntByReference bufferLen = new IntByReference(STR_BUFFER_LEN); int ret = ACBrNFSeLib.INSTANCE.NFSE_EnviarEvento(getHandle(), toUTF8(aInfEvento), buffer, bufferLen); checkResult(ret); return processResult(buffer, bufferLen); } método checkResult(ret) da classe ACBrLibBase protected void checkResult(int result) throws Exception { if (result < 0) { ByteBuffer buffer = ByteBuffer.allocate(STR_BUFFER_LEN); IntByReference bufferLen = new IntByReference(STR_BUFFER_LEN); UltimoRetorno(buffer, bufferLen); throw new Exception(processResult(buffer, bufferLen)); } } // Função para processar o resultado do retorno da biblioteca. método processResult() da classe ACBrLibBase protected String processResult(ByteBuffer buffer, IntByReference bufferLen) { int bLen = bufferLen.getValue(); if (bLen > STR_BUFFER_LEN) { int tamanhoBuffer = (int) (Math.round(bLen * 1.3)); ByteBuffer nBuffer = ByteBuffer.allocate(tamanhoBuffer); IntByReference nBufferLen = new IntByReference(tamanhoBuffer); UltimoRetorno(nBuffer, nBufferLen); return fromUTF8(nBuffer, nBufferLen); } return fromUTF8(buffer, bufferLen); }

Bom dia, @Borante! Obrigado por relatar, vou testar na 2.0.1.213 também.

Bom dia @Eric Bortoleto, Fiz o processo de atualização para a versão 2.0.1.213 a mais recente e agora estou tendo erro ao utilizar a dll. tanto com a versao ACBrLibNFSe-Linux-2.0.1.212 e ACBrLibNFSe-Linux-2.0.1.213 esta dando erro quando vai instanciar a ddl pelo java. O erro esta ocorrendo quando tento gerar o XML e no processo tambem de tansmitir a NFS-e. Voltei a versão antiga e voltou a funcionar porem com o problema no cancelamento arquivo gerado pelo java com o erro: # # A fatal error has been detected by the Java Runtime Environment: # # SIGFPE (0x8) at pc=0x0000789f2f7c4fdb, pid=72845, tid=72846 # # JRE version: OpenJDK Runtime Environment Corretto-21.0.7.6.1 (21.0.7+6) (build 21.0.7+6-LTS) # Java VM: OpenJDK 64-Bit Server VM Corretto-21.0.7.6.1 (21.0.7+6-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # C [libacbrnfe64.so+0x3c4fdb] # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E" (or dumping to /xxxx/commons/core.72845) #

Acho que você tem que informar "ISENTO"

Excelente, muito obrigado

Bom dia colegas, Se alguém tiver um exemplo de preenchimento no padrão da IPM eu agradeço, não encontrei um exemplo de preenchimento deste provedor no exemplo, estou meio perdido, no caso e informar a alíquota 0.10 do ibs onde vai esse percentual e valor nos campos da Uf ou nos campos do município. Grato.

Olá @Marcos Pereda O componente já está apto pra trabalhar com o Pix Automático. No nosso demo do ACBrPIXCD você consegue testar todos os endpoints relacionados a ele. Nesse tópico vc encontra mais detalhes sobre o assunto:

Obrigado Fabrício, achei bem confuso, pois na NT é informado vNFTot = Valor total da NF-e com IBS / CBS / IS, mais realmente no vItem existe essa exceção. Otima Sexta pra todos!

Grato !! Declaracao de Classe !! Ja Ajuda Muito !

Não, ficaram as duas. <serv> <locPrest> <cLocPrestacao>3144805</cLocPrestacao> </locPrest> <cServ> <cTribNac>010101</cTribNac> <cTribMun>001</cTribMun> <xDescServ>xxxxxxxxxxx</xDescServ> </cServ> </serv>

Pessoal, retornando aqui para deixar documentado o resultado da minha análise e o posicionamento oficial da AT&M. Após contato direto, obtive a confirmação de que a orientação divulgada anteriormente pela AT&M está sendo retificada, pois era direcionada apenas a operações com contratação de terceiros (TAC/CTC/ETC na condição de prestador contratado). Isso gerou a interpretação de que todos os transportadores deveriam preencher obrigatoriamente o tpTransp no MDF-e, o que não se aplica quando o veículo é próprio. Esclarecimento final da AT&M Quando o transporte é realizado com frota própria, ou seja, veículo pertencente ao mesmo CNPJ emissor do MDF-e: ✔ Não deve ser informado tpTransp ✔ Não deve ser informado grupo de proprietário ✔ O MDF-e segue o fluxo normal, sem rejeição O preenchimento de TAC / ETC / CTC só é obrigatório quando há prestador de serviço de transporte distinto do proprietário do veículo, como originalmente previsto na regra fiscal. A própria AT&M reconheceu que a orientação publicada estava direcionada a empresas que contratam terceiros, o que causou conflito com casos de frota própria e levou à falha de interpretação do material. Em resumo: Cenário Como informar no MDF-e Frota própria (veículo pertence ao emitente) Sem tpTransp – Sem grupo de proprietário Veículo de terceiro / contratação tpTransp = TAC / ETC / CTC conforme o caso Deixo registrado aqui para facilitar futuras consultas e contribuir com quem encontrar o mesmo impasse. Caso alguém tenha implementação alternativa em seguradoras para frota própria (ex.: envio espelho, consignação, fluxo híbrido) fica aberto o espaço para troca.

Olá pessoal, tudo bem? Estou escrevendo esse tópico para auxiliar na correção do erro: "ERRO AO ESTABELECER CONEXÃO SSL" no TEF PayGo: Possíveis causas do erro: - A versão que está utilizando está vencida(Com o certificado expirado). A PayGo sempre disponibiliza a versão mais atual em sua documentação: https://paygodev.readme.io/docs/visão-geral - Um pdc de produção está sendo configurado com o endereço de homoloção(ou vice-versa), para integrações via DLL, você passa essa configuração atráves do menu admin TEF > "Configuração" > "Nome/ip servidor". Atualmente esses são os endereços corretos: PRODUÇÃO: pos-transac.pgweb.io:31735 | HOMOLOGAÇÃO: pos-transac-sb.tpgweb.io:31735 - O certificado Amazon raiz da máquina pode estar corrompido ou vencido. Como "resetar" por completo esses certificados: - No cmd, execute: 1 – Exportar certificados: certutil -store root > backup_root.txt certutil -store CA > backup_intermediate.txt 2 – Remover certificados corrompidos: certutil -delstore root <Thumbprint> certutil -delstore CA <Thumbprint> 3 – Recarregar certificados: certutil -generateSSTFromWU all.sst certutil -addstore -f root all.sst certutil -addstore -f CA all.sst

Olá pessoal, tudo bem? Estou criando este tópico com o intuito de auxiliar a resolver o erro de "CLASSE INVÁLIDA" na ativação do client PayGo: Esse erro ocorre devido a falta de configurações necessárias na máquina em questão, É necessário que sejam feitos os procedimentos abaixo: 1) No menu iniciar digite "cmd"; 2) Digite "net stop winmgmt" e pressione Enter; 3) Abra o Windows Explorer e localize o caminho para a pasta C:\windows\system32\WBEM\ e renomeie e pasta Repository para algo como RepositoryOLD(Clique com o botão direito e escolha 'Renomear Pasta'). 4) Reinicie a máquina; 5) No menu iniciar digite "cmd"; 6) Digite "net stop winmgmt" e pressione Enter; 7) Digite "winmgmt/resetRepository" e reinicie o computador. Após isso, a máquina iniciará e já será possível ativar o client da PayGo.

Olá comunidade Gostaria de compartilhar com todos vocês um guia de Como iniciar a Homologação TEF usando a CliSiTef a DLL da Fiserv Sobre o ACBr O ACBr é Distribuidor dos produtos e serviços da FISERV Temos condições exclusivas para a comunidade do ACBr, Somos autoridade em TEF. Confira o nosso curso completo, sobre TEF e Meios de Pagamentos Tenha acesso ao nosso Suporte, Demos e Cursos, inscrevendo-se na página: https://projetoacbr.com.br/tef/ Sobre a FISERV A Fiserv é uma líder global em tecnologia para serviços financeiros e pagamentos, presente em mais de 100 países e com mais de 40 anos de atuação. O SiTef (Sistema Inteligente de Transferência Eletrônica de Fundos) é uma solução TEF desenvolvida pela Fiserv para integrar pagamentos eletrônicos diretamente aos sistemas de automação comercial (PDV, ERP, e-commerce). Ele é considerado líder no mercado brasileiro e movimenta bilhões de transações por ano. Sendo o mais aceito, e compatível dos TEFs do mercado Brasileiro O que é a CliSitef ? A CliSiTef, é uma biblioteca desenvolvida pela Fiserv para as plataformas Windows, Linux, que realizam a captura e transações (TEF) através do servidor SiTef. https://dev.softwareexpress.com.br/docs/clisitef/clisitef_documento_principal/ Instalação do SiTef Demonstração. Baixe e instale o SitDemo distribuído pela Fiserv Após a instalação do SitDemo, iremos sobrescrever os arquivos, com a versão já configurada pela equipe do ACBr... NOTA: Se você deseja saber quais são as configurações que já foram aplicadas pela Equipe do ACBr no ZIP, leia esse artigo Baixe o SitDemo, já configurado pela equipe do ACBr, no Link abaixo: Após baixar o arquivo SitDemo_ProjetoACBr.zip, descompacte do arquivo ZIP, a Pasta "SiTef", na raiz do seu disco C:\ Inicializando SiTef Demonstração. Dentro da pasta SiTef, existiram uma série de pastas do ambiente de homologação, a mais importante será a "APLIC.WIN", pasta que carrega todas as aplicações do SiTef. Abrindo a pasta "APLIC.WIN" busque pelo arquivo "SitDemo.exe" e execute-o como administrador. Uma janela como essa será exibida: Nota: Várias outras janelas, abrirão em segundo plano... Isso realmente é o comportamento esperado, do Emulador SitDemo Pronto: agora o seu servidor de homologação já está rodando. Teste de pagamento usando o Demo do ACBr Para realizar um teste de transação, usando o Demo do ACBr, é necessário copiar as DLLs da CliSiTEF na mesma pasta do Executável do ACBr, "TEFAPIDemo.exe"... As DLLs da CliSiTef, podem ser encontradas nos arquivos ZIP como: - clisitef-7.0.117.109.r1-Simulado-Win32.zip (x86, 32 bits) - clisitef-7.0.117.109.r1-Simulado-Win64.zip (x64) Observe que essas DLLs (acima) devem ser utilizadas apenas em ambientes de testes.. as DLLs de Produção não funcionarão em ambientes de Desenvolvimento. IMPORTANTE: Se você compila sua aplicação em 32 bits, sempre use DLLs de 32 bits (mesmo que o Windows seja 64 bits) Configure o arquivo CliSiTef.ini Siga as instruções do tópico abaixo, para criar ou configurar o arquivo de configuração CliSiTef.ini, para ativar a gravação de Logs no ambiente de homologação Execute o TEFAPIDemo e altere o Gerenciador TEF para "tefApiCliSiTEF". Coloque a loja que deseja testar no campo Filial (a loja padrão criada pelo SiTef é 00000000). Roteiro Pré-Homologação SiTef Em nosso curso -> T.E.F e Meios de Pagamentos, já estão disponíveis as aulas sobre o Pré-Roteiro de Homologação - CliSitef Windows. Nesse curso, você poderá acompanhar nossos desenvolvedores, explicando a lógica de cada um dos testes do roteiro. Envio de Arquivos Pré-Homologação SiTef Durante os os testes do roteiro, você deverá coletar os Logs e comprovantes de transação... O Artigo abaixo, explica passo a passo esse processo, e também detalha para onde e como os Logs devem ser enviados para analise... Suporte da Equipe do ACBr Se você tem contrato de Parceria com o ACBr, para a Distribuição de TEF, você pode contar com a ajuda e Suporte de nossos técnicos e desenvolvedores Acesso o canal #sitef-homologação, no Discord do ACBr Ou poste suas dúvidas, aqui mesmo no fórum, na área Homologação TEF SiTEF

Certamente isso será feito @Juliomar Marchetti, mas a proposta agora era só fazer o básico do básico para voltar a ter o ambiente de homologação de NFC-e de GO funcionando, já que exigiram os campos da reforma tributária. Consegui fazer funcionar com a proposta que citei, então para o básico, considerando um único produto de R$ 10,00, teríamos que preencher: vItem := 10.00; ... IBSCBS.CST := cst000; IBSCBS.cClassTrib := '000001'; IBSCBS.gIBSCBS.vBC := 10.00; IBSCBS.gIBSCBS.gIBSUF.pIBSUF := 0.10; // Fixo em 2026 IBSCBS.gIBSCBS.gIBSUF.vIBSUF := 0.01; IBSCBS.gIBSCBS.gIBSMun.pIBSMun := 0.00; IBSCBS.gIBSCBS.gIBSMun.vIBSMun := 0.00; IBSCBS.gIBSCBS.vIBS := 0.01; IBSCBS.gIBSCBS.gCBS.pCBS := 0.90; // Fixo em 2026 IBSCBS.gIBSCBS.gCBS.vCBS := 0.09; ... Total.IBSCBSTot.vBCIBSCBS := 10.00; Total.IBSCBSTot.gIBS.vIBS := 0.01; Total.IBSCBSTot.gIBS.gIBSUFTot.vIBSUF := 0.01; Total.IBSCBSTot.gIBS.gIBSMunTot.vIBSMun := 0.00; Total.IBSCBSTot.gCBS.vCBS := 0.09; Total.vNFTot := 10.00; Com isso, é possível efetuar um teste autorizando uma NFC-e em homologação em GO, preenchendo os atributos da Reforma Tributária.

Muito legal... O @EliasCesar, já está estudando a criação de um componente ACBrCalcRT

aproveitei essa dica e implementei no acbrmail no teste a funcionalidade ficou perfeito, autentica, pega o refleshtoken valida e envia sem nem uma mudança no componente.

Bom dia @daniel_mirassol perdão pela demora... Vc pode fazer em duas etapas: 1ª: Primeiro vc autentica no OAuth para gerar o acess token procedure xxxxx.OnTokenGerado(const pAcessToken, pRefreshToken: string; const pDataExpiracao: TDateTime); begin // aqui vc consegue pegar os tokens gerados apos fazer login na conta do gmail // vc deve salvar esses tokens para serem usados depois end; var config: TConfigOAuth; fOAuth2: TOAuth2; begin config.ClientID := '< seu client id >'; config.ClientSecret := '< seu client secret >'; config.OnGenerateToken := OnTokenGerado; fOAuth2 := TGMailOAuth.Create(pConfig); fOAuth2.Authenticate; // aqui vai pedir pra fazer login na conta do gmail end; 2ª: Com o token gerado agora vc alimenta o componente do ACBrMail function RefreshTokenOAuth: string; var config: TConfigOAuth; fOAuth2: TOAuth2; begin config.ClientID := '< seu client id >' config.ClientSecret := '< seu client secret >'; config.AccessToken := '< access token gerado anteriormente >'; config.RefreshToken := '< refresh token gerado anteriormente >'; fOAuth2 := TGMailOAuth.Create(pConfig); fOAuth2.RefreshNewToken; Result := fOAuth2.getAccessToken; end; var fACBrEmail: TACBrMail; begin fACBrEmail := TACBrMail.Create(nil); ... ... fACBrEmail.Username := 'xxxx'; fACBrEmail.Password := RefreshTokenOAuth;