Painel de líderes

Olá, pessoal. Temos o prazer de anunciar que o novo componente ACBrIMendes já está disponível no SVN! Sobre o ACBrIMendes: O componente ACBrIMendes oferece uma integração simplificada com a API Gestor Tributário 3.0. Ele automatiza o gerenciamento de dados fiscais da sua empresa, prevenindo cobranças de impostos indevidas e apontando riscos de prejuízos. Com isso, proporciona mais segurança tributária e uma melhora direta no fluxo de caixa. Disponível em: - Fonte: https://svn.code.sf.net/p/acbr/code/trunk2/Fontes/ACBrTCP/ACBrIMendes.pas - Programa exemplo: https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrTCP/ACBrIMendes/

Olá Pessoal, Após a atualização dos fontes dos componentes do ACBr ao compilar as aplicações estão aparecendo uma quantidade enorme de Warning com mensagens indicando que um determinado Símbolo esta depreciado e orienta a usar um tipo ou método que se encontra em uma determinada Unit. Primeiro porque isso esta ocorrendo? A resposta é muito simples, estamos realizando um processo de migração, ou seja, estamos deixando de utilizar as units que se encontram na pasta PCNComum. Os componentes que emitem DF-e (por exemplo o ACBrNFe), deixaram de utilizar as units pcnGerador e pcnLeitor para realizar a escrita e a leitura do XML, eles agora se utilizam das units ACBrXmlWriter e ACBrXmlReader, estas ultimas se demonstraram ser mais velozes. Para vocês terem uma ideia um CT-e com 1800 NF-e vinculadas estava levando mais de 6 minutos para ser lido usando o pcnLeitor. Com o ACBrXmlReader ele foi lido em apenas 6 segundos. Chegou a vez de deixarmos de usar o pcnConversao e passar a utilizar o ACBrDFe.Conversao. Poderíamos simplesmente realizar a troca, mas essa atitude com certeza iria quebrar a compilação de suas aplicações e a solução seria abrir a unit da sua aplicação que não esta compilando e realizar a troca. Resolvemos então fazer alterações na unit pcnConversao para que os tipos e funções de conversão pudessem conviver com os tipos e funções de conversão da unit ACBrDFe.Conversao. E uma dessas alterações na unit pcnConversao visa gerar esses Warnings para alertar você desenvolvedor a realizar a troca. Notem que vários desses Warnings se referem as units dos próprios componente, esses nós vamos iniciar em breve a realizar as trocas. Por fim não menos importante Warnings não são erros e sim alertas, eles não impedem que a sua aplicação funcione corretamente.

Olá, comunidade ! Nos últimos dias temos recebidos diversos relatos em nosso Discord e em nosso Fórum de problemas com certificado A3. Todos os relatos tem em comum o mesmo erro: Tudo indica que este problema está relacionado a alguma atualização recente do Windows, visto que ele começou a ocorrer repentinamente. Como é explicado AQUI a configuração WinCrypt que é utilizada para certificados A3 faz uso da própria API do Windows. Alguns membros relataram ter sanado o problema ao desinstalar e instalar novamente o certificado. Um agradecimento ao membro de nossa comunidade @RicardoAGRO1 compartilhou no canal #sefaz em nosso servidor do Discord o link: Podem ocorrer problemas de autenticação do SmartCard com a atualização do Windows de outubro de 2025 com um passo a passo para a solução do problema.

Com o advento da reforma tributária, os municípios são deixados com uma escolha: Aderem ao padrão nacional na íntegra ou continuam usando provedor próprio no formato aderindo ao padrão nacional no formato de compartilhamento de informações. Se escolhida a segunda opção, dois caminhos podem ser seguidos: No caminho mais simples, o provedor cria uma API própria para recepcionar os arquivos XMLs segundo o leiaute do Padrão Nacional. Nesta abordagem, o leiaute utilizado é o já existente do padrão nacional, então basta saber qual é a URL da API para comunicação e os end-points. No caminho mais complexo, o provedor altera o leiaute que ele já usa, adicionando novos campos para receber as informações que ela vai compartilhar posteriormente com o padrão nacional. Padrão Nacional A quantidade de municípios que aderiram ao Padrão Nacional é cada vez maior e pode ser conferida em um Dashboard alimentado e atualizado em tempo real. Acesse o Dashboard AQUI. Lembrando que as soluções ACBr já atendem ao padrão nacional. Provedores com API Própria para atender o Padrão Nacional com a Reforma Tributária. Última atualização: 06/01/2026 Observação: Vale reforçar que devido a relação quantidade de provedores x prazo, o foco das implementações inicialmente tem sido os métodos de emissão da NFS-e. Provedor Requisito Cidade testada Cidades atendidas* Emissão funcionando ABase Informar o Token em WSChaveAcesso Boa Vista do Burica/MS 39 Em testes Betha Vai usar WebService Soap Dourados/MS 403 Envio OK Coplan Vai usar WebService Soap Barra do Garças/MT 31 Em testes Citta Enviar o XML da NFS-e São Valentim do Sul/RS 24 Envio OK Digifred Vai usar WebService Soap Ibirubá/RS 21 Envio OK EL Informar o Token em WSChaveAcesso Aracruz/PE 155 Envio OK Infisc - Campo Bom/RS 9 Envio OK ISSNet WS Soap/Permite Lote de DPS - 25 Aguardando as URLs de homologação Pronim Permite o envio de um lote de DPS Regente Feijó/SP 184 Envio OK RLZ - Barretos/SP 9 - SilTecnologia WS Soap/Enviar o XML da NFS-e Franca/SP 16 Retorno Vazio SimplISS - Blumenau/SC 27 Envio OK (Ainda não aceita os campos IBSCBS) Tiplan - Americana/SP 8 Envio OK * Estimativa aproximada Provedores que alteram o layout em uso para atender a Reforma Tributária. Última atualização: 06/01/2026 Provedor Requisito Cidades Atendidas* Emissão funcionando EloTech Versão 2.03 138 Envio OK FintelISS Versão 2.02 4 O webservice da prefeitura não aplicou o novo Schema GeisWeb Próprio 7 Envio OK Ginfes - 22 Giss - 18 Envio OK IPM - 188 Envio OK ISSBarueri - 1 ISSe - 1 Envio OK ISSSaoPaulo Versão 2.00 1 Envio OK Publica Versão 1.00 31 Envio OK SigISSWeb Próprio 11 Envio OK SpeedGov Versão 2.00 32 Tinus Versão 2.03 44 Envio OK WebISS Versão 2.02 87 Envio OK * Estimativa aproximada

Bom dia , estou tentando enviar uma nfse no exemplo do acbrnfsex para teste e está me retorno o seguinte erro : Parâmetros de Envio Numero do Lote: 3 Parâmetros de Retorno Numero do Prot: Numero da Nota: Link : Código Verif. : Sucesso : False Erro(s): Código : X800 Mensagem: Erro de Validação: --> 1871 - Element '{http://www.sped.fazenda.gov.br/nfse}IBSCBS': This element is not expected. Quando desmarco a opçao reforma tributaria a nota é validada, alguma dica de como acertar isso. Obrigado Paulo Sergio

Olá, comunidade ACBr! Ficamos felizes em anunciar o lançamento da ACBrLibExtratoAPI! A ACBrLibExtratoAPI faz parte do pacote ACBrBaas, que foi criado para facilitar a integração de sistemas com serviços bancários e APIs de pagamento. Baixe a ACBrLibExtratoAPI: Na versão DEMO Na versão PRO Leia a documentação completa AQUI Até mais!!!

Show, ajudou muito. Obrigado

"ACBrNFeDANFEFR" esse componente é o DANFE para fast report, vc vai precisar instalar o fast report de depois o danfe para fast report, ou troca ele pelo gerador do fortes report, no caso esse que vc mostrou acima. (seu problemas esta mais em usar o lazarus do que nos componentes acbr) como eu disse no post anterior, vc vai precisar adicionar qualquer componente utilizado nessa unit. (as dependencias de instalção de cada componente é inerente a cada um ) vc precisa pesquisar e instalar tudo que for necessário, a forma como vai ser instalado e utilizado depende de cada um

O que te impede de, enviar, obter a resposta, fazer as atualizações no seu BD, e só depois mandar imprimir ? ACBrNFe1.Enviar(aLote, false, true) <- Segundo parametro false, para não imprimir. e somente depois imprimir ACBrNFe1.NotasFiscais.Items[0].Imprimir

Boa tarde @fabio.lobosque, Já esta no SVN.

Boa tarde @JeannyPaiva, Já esta no SVN.

Boa tarde @brsamn, Já esta no SVN.

Bom Dia !!! É isso mesmo, algum erro no WebService deles pois tenho XML autorizado dia 13/10 com essas Tags. Vamos esperar um retorno do Sefaz.

Olá, comunidade ! Foi publicado no Diário Oficial do Estado de São Paulo o Decreto Nº 69.981, de 18 de Outubro de 2025, internalizando na legislação do estado a obrigatoriedade do preenchimento do Código do Benefício Fiscal (cBenef) ao realizar a emissão de uma NF-e ou de uma NFC-e. A adoção será feita de forma gradual, com as regras de validação sendo ativadas no ambiente de homologação a partir de 12/01/2026 e no ambiente produção a partir de 06/04/2026, conforme estabelecido na Nota Técnica 2019.001 v1.70. As tabelas de CST x cBenef para o estado podem ser encontradas AQUI. Lembrando que o campo já existe no leiaute da NF-e\NFC-e e pode ser alimentado da seguinte maneira: Caso use componente nativo para Delphi/Lazarus. uses ACBrNotasFiscais, ACBrNFe.Classes; //... var NotaF: NotaFiscal; Produto: TDetCollectionItem; begin NotaF := ACBrNFe.NotasFiscais.Add; //Preenche demais informações... Produto := NotaF.NFe.Det.New; Produto.cBenef := ...; //Preenche demais informações. end; Caso use ACBrMonitorPLUS ou ACBrLib. [Produto001] cBenef=... ;Preenche as demais informações...

Olá Pessoal, Essa é uma boa pergunta. E a resposta é muito simples esta pronto e não esta pronto. Como assim? Até o momento temos a NT 2025/004 que traz as alterações no layout da NFS-e Padrão Nacional para a Reforma Tributária, mas não temos Manuais dos provedores que seguem a versão 1 do layout da ABRASF nem dos que seguem a versão 2 e nem dos provedores que tem layout próprio. O que temos pronto no ACBrNFSeX? Implementação dos novos grupos e campos visando a Reforma Tributária para o Padrão Nacional. Sendo assim através do programa exemplo é possível gerar o XML do DPS (Declaração de Prestação de Serviço), mas ao fazer isso vai ocorrer erro de validação. O motivo do erro é que os Schemas que temos não contempla os novos grupos e campos da Reforma Tributária. E o ambiente de homologação que a Receita Federal chama de Produção Restrita não foi alterado para aceitar os novos grupos e campos. Resumindo. Já esta no SVN as alterações no componente ACBrNFSeX para gerar o XML do DPS (Padrão Nacional) com os novos campos. Não vai ser possível validar e nem enviar para o ambiente de homologação. Assim que tivermos mais noticias sobre a Reforma Tributária na NFS-e, vamos divulgar.

segue o arquivo com os intents necessarios.AndroidManifest.template.xml nesse arquivo tem um trecho: <service android:name="br.com.setis.interfaceautomacao.ComunicacaoServico" android:exported="true" android:configChanges="orientation|screenSize"> <intent-filter> <action android:name="br.com.setis.interfaceautomacao.SERVICO"/> </intent-filter> </service> para o demo ser mostrado no "PGIntegrado-v4.1.27.13_CERT-signed.apk" como mostra a imagem abaixo. desde já agradeço a atenção.

Boa tarde Juliomar, Certo, Quando o cenário é apenas um CTE no MDFE não tenho saída se não o preenchimento da tag InfLotacao é isso? Se eu destacar as informações do InfLotacao estou dizendo que é uma carga lotação e com isso meu Cliente (contratante) é obrigado a cumprir com algumas regras fiscais. Cenário qual não é verdade, já que não é uma carga lotação, simplesmente não existem outras cargas. Não tenho outra saída?

Sim mas ali deve de informar um cep de saida e um de chegada. somente isso deve de informar <prodPred> <tpCarga>04</tpCarga> <xProd>CHAVE PHILLIPS 3/16</xProd> <cEAN>7899009080365</cEAN> <NCM>82054000</NCM> <!-- Informações da carga lotação --> <infLotacao> <!-- Informações da localização do carregamento do MDF-e de carga lotação --> <infLocalCarrega> <!-- CEP onde foi carregado o MDF-e --> <CEP>91740011</CEP> </infLocalCarrega> <!-- Informações da localização do descarregamento do MDF-e de carga lotação --> <infLocalDescarrega> <!-- CEP onde foi descarregado o MDF-e --> <CEP>88330012</CEP> </infLocalDescarrega> </infLotacao> </prodPred> https://www.oobj.com.br/bc/article/rejeição-726-o-grupo-de-informações-da-carga-lotação-deve-ser-informado-como-resolver-986.html