Painel de líderes

Gostaria de desejar um Feliz ano novo para todos que colaboram e mantem o excelente projeto ACBR pelo grande trabalho desempenhado neste 2025. Este projeto é de grande valia para todos os programadores do Brasil. Um ótimo 2026 a todos!

Olá comunidade ! Na data de 30/12/2025 começamos a receber múltiplos relatos de problemas ao realizar o envio de um evento de cancelamento de NFS-e junto ao Padrão Nacional. Após investigação foi constatado que houve uma atualização dos schemas no dia 26/12/2025, trazendo alterações que impactaram no envio dos eventos. Visando sanar o problema no cancelamento da NFS-e, foram enviadas ao SVN alterações nas Revisions 43956 e 43957 fazendo as correções necessárias para que o cancelamento possa ser realizado com sucesso. Portanto se você utiliza componente nativo para Delphi ou Lazarus atualize seus fontes e reinstale o ACBr. Caso utilize ACBrLibNFSe, faça o download da versão mais recente da mesma disponível no fórum: Aqueles que utilizam ACBrMonitorPLUS também precisam atualizar: É importante que além da solução ACBr, também sejam atualizados os arquivos de schema. As demais alterações trazidas pelos schemas serão revisadas na tarefa #ACBR-8678 e serão atualizadas neste tópico a medida que houverem novidades. As modificações com a atualização dos schemas que foram relacionadas são: tiposComplexos_v1.00.xsd: Elimina o grupo para exploração rodoviária; => Vai ficar na NFS-e Via agora. Elimina o grupo para locação de dutos; => Vai ficar na NFS-e Via agora. xOutInf sai do grupo valores e sobe um nível. tiposEventos.xsd: Elimina o campo nPedRegEvento.(Resolvido nas revisions 43956 e 43957) Altera a descrição dos eventos permitindo acentos e adicionando "Manifestação de NFS-e" nos eventos de manifestação. No evento TE202205 os elementos de infRej sobem de nível e o grupo deixa de existir. No evento TE203206 os elementos de infRej sobem de nível e o grupo deixa de existir. No evento TE204207 os elementos de infRej sobem de nível e o grupo deixa de existir. No evento TE205208 os elementos de infRej sobem de nível e o grupo deixa de existir. No evento TE305102 os elementos xMotivo e codEvento invertem a ordem em que aparecem no arquivo. Elimina o tipo complexo TCListaEventos tiposSimples.xsd: Elemento TSSerieDPS ganha um regex para limitar os valores possíveis no campo. TStat ganha novos valores possíveis. Elimina os eventos e907202 e e967203 Elemento TSIdPedRegEvt muda. (Resolvido nas revisions 43956 e 43957)

Isso ai mano, sigamos em 2026, muitas batalhas para quebrar/conquistar.

Sim. Veja o que diz a NT 2025/002:

Situação=2 indica lote em processamento Efetue novas consultas da situação até receber os retornos 3 - Lote Processado com Erros e 4 - Lote Processado com sucesso. [Erro1] Codigo=E861 Correcao= Descricao=Protocolo recebido mas ainda não processado. Sua consulta do lote confirma que ainda não foi processado. Se continuar recebendo somente lote em processamento, tente contato com o provedor para verificarem o que há de errado no processamento do lado deles.

Lendo o log, vc executou o metodo: 31/12/25 12:26:58:629 - NFSE_ConsultarSituacao(20139736139,00001257 ) E tivemos este retorno: 31/12/25 12:26:58:715 - SetRetorno(0, [Situacao] Lote= Protocolo=20139736139 Situacao=2 XmlEnvio=<Arg xmlns="http://www.tinus.com.br"><Prestador><Cnpj>01537376000100</Cnpj><InscricaoMunicipal>0401081</InscricaoMunicipal></Prestador><Protocolo>20139736139</Protocolo></Arg> XmlRetorno=<ConsultarSituacaoLoteRpsResult><Situacao>2</Situacao></ConsultarSituacaoLoteRpsResult> ) O Segundo método indicado pelo @Renato Rubinho, ConsultarLoteRps() não encontrei no log, não foi executado o método.

Olá, A tarefa ACBr-8597 já foi concluída? Nao tenho solução de contorno por aqui, precisamos emitir NFSe pra Santos e Jundiai que são GISS também.

Bom dia, Criada a tarefa ACBR-8684 para avaliação. Para manter seu sistema atualizado acompanhe o topico:

Obrigado, vou olhar os links. Com relação ao e-mail já enviei alguns para eles mas não obtive resposta.

Existe e estou também investigando

Bom dia, Como já recebeu orientação do @Diego Foliene e dos modelos de INI e entendemos que deseja interação com outros usuários da comunidade para obter o exemplo pronto vamos manter este tópico na área aberta e marcado como solucionado apenas para nosso controle de atendimento. Obrigado.

Entendendo o problema De acordo com a planilha ANEXO_I-SEFIN_ADN-DPS_NFSe-SNNFSe-v1.00-20251216 que contém o leiaute da NFS-e e as regras de validação aplicadas pela API do Padrão Nacional, está é a regra de validação que correspondente a esta rejeição: Campo Regra de Validação Código Rejeição indTotTrib Se a situação do emitente da DPS perante o Simples Nacional na data de competência informada for ME/EPP, o choice indTotTrib nunca poderá ser informado. E0712 Para ME/EPP indTotTrib nunca poderá ser informado. Ainda de acordo com o mesmo leiaute, a tag indTotTrib faz parte de um "elemento escolha" junto dos grupos vTotTrib, pTotTrib e pTotTribSN. Ou seja, o arquivo XML só vai poder ter o vTotTrib ou o pTotTrib ou o indTotTrib ou o pTotTribSN, mas nunca mais de um deles. Se você está recebendo essa rejeição, isso significa que seu arquivo está sendo enviado com o elemento indTotTrib, quando deveria ser com um dos outros 3. Como resolver? No momento de geração do XML, uma lógica é aplicada para definir qual é o grupo que vai ser gerado. Verifica se foram preenchidos os valores que compõe vTotTrib. Se forem maiores do que zero, gera o grupo vTotTrib; Se não foi gerado o grupo no passo anterior, verifica se foram preenchidos os valores que compõe pTotTrib. Se forem maiores do que zero, gera o grupo pTotTrib. Se não foi gerado o grupo no passo anterior, verifica se o valor de pTotTribSN é maior do que zero. Se for, gera o grupo pTotTribSN. Se não foi gerado o grupo no passo anterior, verifica se o valor de indTotTrib é zero, se for, gera o grupo indTotTrib. Considerando isso, é preciso preencher as informações de modo que o indTotTrib não seja gerado. Caso utilize ACBrNFSeX para Delphi e Lazarus Para gerar o vTotTrib preencha: NFSe.Servico.Valores.totTrib.vTotTribFed := NFSe.Servico.Valores.totTrib.vTotTribEst := NFSe.Servico.Valores.totTrib.vTotTribMun := NFSe.Servico.Valores.totTrib.indTotTrib := TindTotTrib.indSim; Para gerar o pTotTrib preencha: NFSe.Servico.Valores.totTrib.pTotTribFed := NFSe.Servico.Valores.totTrib.pTotTribEst := NFSe.Servico.Valores.totTrib.pTotTribMun := NFSe.Servico.Valores.totTrib.indTotTrib := TindTotTrib.indSim; Para gerar o pTotTribSN preencha: NFSe.Servico.Valores.totTrib.pTotTribSN := NFSe.Servico.Valores.totTrib.indTotTrib := TindTotTrib.indSim; Caso utilize ACBrMonitorPLUS ou ACBrLib Para gerar o vTotTrib preencha: [totTrib] vTotTribFed= vTotTribEst= vTotTribMun= indTotTrib=1 Para gerar o pTotTrib preencha: [totTrib] pTotTribFed= pTotTribEst= pTotTribMun= indTotTrib=1 Para gerar o pTotTribSN preencha: [totTrib] pTotTribSN= indTotTrib=1

Contabilidade falando besteira? Imagina isso é "raro" de acontecer.. rsrs.

Olá, Devido a contradições na leitura do campo "Nosso Número" nos arquivos de Retorno dos bancos, adicionamos a propriedade: LerNossoNumeroCompleto no componente ACBrBoleto para definir a forma de leitura desse campo. Ao gerar a Remessa o próprio componente se encarrega de calcular o digito que complementa o Nosso Número e também outras particularidades. Mas ao ler o arquivo de Retorno o componente sempre lê apenas o Número Fixo, assim como é passado na geração da remessa, porém muitos queriam obter esse número de forma completa, ou seja, com o dígito verificado e demais particularidades. Como solução criamos uma nova propriedade "LerNossoNumeroCompleto" para configurar isso, com essa opção selecionada pode obter o NossoNumero completo assim como é retornado no arquivo, caso contrário permanece da mesma forma, lendo apenas o Número Sequencial, conforme alimentado no componente. Essa nova propriedade já está configurada para o Banco Sicred, se houver necessidade para os demais Bancos, pode ser utilizado essa configuração para o mesmo fim.