Painel de líderes

Olá comunidade ! Foi publicado em 09/04/2026 o Despacho nº 18/2026, que divulga diversos Ajustes SINIEF. Entre eles, destaca-se o Ajuste SINIEF nº 12/2026, que revoga o Ajuste SINIEF nº 11/2025. Na prática, essa revogação cancela a regra que determinava o fim da NFC-e para operações destinadas a CNPJ, tema que já havíamos abordado anteriormente aqui. Com isso, não será mais incluído no Ajuste SINIEF nº 19/2016 o seguinte dispositivo: De acordo com a cláusula segunda, este ajuste entra em vigor na data de sua publicação.

Na geração do Registro Transação no CNAB240, registro R, o campo de Percentual de Multa (posições 75-89) era enviado conforme valor informado em PercentualMulta, isto independente se a propriedade MultaValorFixo estivesse setada ou não. Com a correção, será levado em consideração a propriedade MultaValorFixo para enviar o campo PercentualMulta conforme é preenchido caso MultaValorFixo seja falso e caso seja verdadeiro será convertido o PercentualMulta de valor para percentual conforme método ConverterMultaPercentual. Caso envie o MultaValorFixo como True: PercentualMulta := 5,00 MultaValorFixo := True; ValorDocumento := 150,00 Resultado := 3,33 No arquivo foi: 000000000000333 Caso envie o MultaValorFixo como False: PercentualMulta := 5,00 MultaValorFixo := False; ValorDocumento := 150,00 Resultado := 5,00 No arquivo foi: 000000000000500 Correção disponível na revisão 45720.

Olá comunidade ! Foi publicado no dia 09/04/2026 o DESPACHO Nº 18, de 8 de Abril de 2026 trazendo múltiplos Ajustes Siniefs. Dentre eles temos o Ajuste SINIEF Nº 5, de 6 de Abril de 2026 que altera o Ajuste SINIEF nº 21, de 10 de dezembro de 2010, alterando a redação do § 2º da cláusula terceira de: Para: A nova redação remove os casos de exceção e estabelecendo que deve ser emitido um MDF-e por UF de descarregamento agregando as cargas de cada UF para todos os casos. Essa alteração entra em vigor a partir de 01/06/2026 conforme cláusula segunda do referido ajuste:

Olá comunidade ! Foi publicado no dia 09/04/2026 o DESPACHO Nº 18, de 8 de Abril de 2026 trazendo múltiplos Ajustes Siniefs. Dentre eles temos o Ajuste SINIEF Nº 4, de 6 de Abril de 2026 que altera Ajuste SINIEF nº 9, de 25 de outubro de 2007 incluindo os §§ 3º e 4º ficam acrescidos à cláusula terceira-B do referido ajuste: A modificação estabelece que a correção de valores no CT-e Simplificado deverá ser feita via CT-e de Substituição e dispensando a necessidade de evento de CT-e em desacordo no caso em questão. Essa alteração entra em vigor a partir de 01/06/2026 conforme cláusula segunda do mesmo ajuste:

Aparentemente esse projeto foi feito com versão (bem) antiga do ACBr. Os erros são de propriedades que foram renomeadas em um refactoring em 2018: No caso, a princípio, ignorar os erros e configurar novamente com as novas propriedades, se assim for o caso.

fiz para um cliente especifico usando evolution api (https://github.com/EvolutionAPI/) com servidor próprio por conta e risco do cliente(pode gerar banimento) no discord foi postado um serviço(https://bsbzap.com/) não conheço. mas você tambem pode usar a api oficial da meta.

Olá comunidade ! Foi publicado no dia 09/04/2026 o DESPACHO Nº 18, de 8 de Abril de 2026 trazendo múltiplos Ajustes Siniefs. Dentre eles temos o Ajuste SINIEF Nº 8, de 6 de Abril de 2026 que altera o Ajuste SINIEF nº 49, de 5 de dezembro de 2025. Em sua cláusula primeira, ele atualiza a redação de alguns itens para o seguinte valor: A nova redação altera as regras para emissão da NF-e de entrada utilizada nos casos de retorno por recusa total, recusa parcial ou não localização do destinatário. A cláusula segunda adiciona o seguinte inciso a cláusula quinta: Isso faz com que além dos campos mencionados na cláusula anterior, também seja necessário informar o destinatário da NF-e de saída original ao emitir uma NF-e de entrada para anulação total da operação de saída original quando houve retorno por recusa total ou parcial. A cláusula terceira revoga o § 1º da cláusula quinta do Ajuste SINIEF nº 49/25: Na prática: A revogação desse parágrafo remove as regras que tratavam da emissão de NF-e de débito pelo destinatário nos casos de recusa parcial, simplificando o processo e concentrando a regularização na emissão da NF-e de entrada pelo remetente. Por fim, a cláusula quarta estabelece que o ajuste entra em vigor a partir de 04/05/2026

Bom dia. @Juliomar Marchetti essa alteração não está lendo o conteúdo dos retornos de eventos... O - <evtTotal id="ID900100000000001184948627"> é minúsculo, diferente do <evento Id="ID1087418990000002026040809311407470"> que é maiúsculo;

Pelo que eu saiba não teve nenhuma alteração no ACBr em relação ao provedor da GeisWeb

Olá Pessoal, É com muita alegria que venho comunicar a todos que com a colaboração do nosso colega @Jhonlenon Ribeiro e com mais alguns ajustes conseguimos consumir os serviços disponibilizados no novo webservice do provedor ISSNet que trabalha com o layout do Padrão Nacional portanto atende a Reforma Tributária. Agora não esta mais retornando a mensagem de que o serviço esta um construção. Quem desejar realizar testes deve seguir as orientações do nosso consultor @Diego Foliene na postagem anterior a esta. Para quem utiliza o componente, favor atualizar todos os fontes de todas as pasta, reinstale o ACBr e faça os testes. Quem utiliza o ACBrLibNFSe ou o ACBrMonitor favor aguardar uma nova versão. Até a data de hoje (09/04/2026) não temos as URLs de produção somente a de homologação, sendo assim os testes deveram ser realizado em ambiente de homologação. Caso vocês venham conseguir a URL de produção para o novo webservice de alguma cidade favor criar um tópico no fórum informando a cidade e a URL. Desde já o meu muito obrigado a todos.

Criado a tarefa ACBR-9238 para análise, assim que concluida reportamos aqui.

Bom dia, A partir de 01/04, entrou em Vigor as novas normas do XML, mudou as URL's também, alguém já está emitindo no padrão novo? @Charlles Lopes @João Antônio https://nfse.cotia.sp.gov.br/ords/cotia/ws/nfe/disponivel https://nfse.cotia.sp.gov.br/ords/cotia/ws/nfe/modelo_xml https://nfse.cotia.sp.gov.br/ords/cotia/ws/nfe/consulta_nota https://nfse.cotia.sp.gov.br/ords/cotia/ws/nfe/cancelar_nota

Bom dia @Jhonlenon Ribeiro, Você poderia anexar o XML soap de envio para que eu possa ver como esta montado a mensagem de cabeçalho, pois para mim esta acusando que o cabeçalho esta errado. Desde já muito obrigado pela colaboração.

Olá Pessoal, Tenho boas noticias para vocês que utilizam o componente ACBrNFSeX com Fast Report. Hoje (06/04/2026) foi enviado para o SVN a implementação em Fast Report para a impressão do DANFSE segundo o layout do Padrão Nacional. Lembrando da nova propriedade de configuração para que possamos informar o caminho e o nome da imagem referente ao logo da NFS-e. Sendo assim temos as propriedades Logo para informar o caminho e o nome da imagem do logo da prefeitura e agora a propriedade LogoNFSe para o logo da NFS-e. Foi disponibilizado também na pasta Delphi e Lazarus dos programas exemplos o arquivo PNG referente ao Logo da NFS-e. O fr3 a ser usado será DANFSEPadraoNacional.fr3 O mesmo está compatível com versões mais básicas do fast report. também temos um exemplo para testar caso venha a ter erros ao abrir ele basta excluir o arquivo NFSe.dproj e abrir NFSe.dpr Ele também deve funcionar com versões 7 ao 13.1 e fast report 3,4,5,6, 2024,2025 e 2026 no modelos Embarcadero Edition, Standard, Professional e Enterprise Qualquer problema por favor crie um tópico no fórum relatando o problema encontrado. Detalhe importante, o XML a ser carregado para poder gerar o DANFSE no Padrão Nacional obrigatoriamente tem que estar no layout da NFS-e Padrão Nacional, caso contrario não vai funcionar. Atenção e somente lembrança para quem já usa : Deve se informar o fr3 no path ACBrNFSeXDANFSeFR1.FastFile := 'seupath\DANFSEPadraoNacional.fr3';

Boa tarde @Diogo Loff, Já esta no SVN.

Para quem está com esse problema, aqui consegui arrumar mudando o tipo de etiqueta para GAP, no programa de utility, por algum motivo o padrão vem em tarja preta

Olá. Identifiquei um problema na unit ACBrBoletoFCFR.pas, a princípio com o Delphi 12 (não testei as versões anteriores), onde ao colocar o componente no formulário, é disparado o erro "Invalid Parameter". Analisando o arquivo fonte dessa unit, identifiquei que o erro ocorre em todas as linhas onde haja o comando <dataseXXXt>.CreateDataSet. O problema ocorre porque se faz necessário declarar a unit MidasLIb no uses do módulo. Fazendo isso, o componente volta a funcionar normalmente. ENTRETANTO, isso cria uma dependência enorme da distribuição da midas.dll. O componente TClientDataSet é utilizado aqui apenas para a criação de um dataset somente em memória, sem uma tabela física. Eu acredito que o TClientDataSet possa ser substituido pelo TFDMemTable, do Firedac, que não cria dependências externas. Peço então aos mantenedores do projeto, que deem uma atenção para esse assunto e, se possível, possam realizar a correção da unit incluindo o MidasLib na sua cláusula Uses, ou realizando a substituição do TClientDataSet pelo TFDMemTable. Desde já agradeço pela cordial atenção. Francis Lay L. Silva