Painel de líderes

Foi publicada a versão 25.2.A das tabelas fornecidas pelo IBPT, às quais já se encontram também em nosso SVN. As novas tabelas tem a vigência de 20/06/2025 até 31/07/2025. Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto", não se esqueça de realizar a atualização de seus clientes. Fonte: De Olho no Imposto

Bom dia, Inclusão Instituição SB Cash Alterações no ACBrBoleto 1: ACBrBancoSBCash - inclusão de nova Unit 2: cobBancoSBCash 3: 482: Result := CobBancoSBCash; 4: CobBancoSBCash : fBancoClass := TACBrBancoSBCash.create(Self); ACBrBoleto.pas ACBrBancoSBCash.pas

https://www.gov.br/esocial/pt-br/noticias/prorrogacao-da-atualizacao-de-certificado-do-esocial-para-um-novo-padrao-de-seguranca  Os empregadores devem atualizar seus sistemas para um novo padrão a partir de 2026. Aimplantação de um novo padrão de segurança, que havia sido prevista para 30 de junho deste ano, foi adiada para 2026, para permitir mais tempo de adaptação para os usuários do eSocial. O cronograma de implantação, com as datas para a produção e produção restrita, será publicado em breve. A utilização dos ambientes web do eSocial, inclusive os módulos simplificados, não será impactada.

Reinstale os componentes marcando a opção Usar ACBrXMLDocument

Olá pessoal! A partir de 30/06/2025 o web service do e-Social vai implementar em seus servidores de recepção e consulta de lotes de eventos um novo certificado visando adotar um padrão de segurança mais robusto baseado algoritmo SHA-384 combinado com RSA. Aplicações que não suportem essa configuração poderão apresentar falhas de conexão. O ACBr está pronto para esta mudança? A equipe de consultores está analisando as informações disponibilizadas e avaliando os fontes para confirmar se existe necessidade de alguma alteração nos fontes do ACBr. Assim que houver novas informações este tópico será atualizado Este tópico foi baseado em notícia publicada originalmente AQUI.

Boa tarde! De maneira simplificada, o método NFSE_GerarLote vai criar um arquivo, assinar e validar ele com os schemas, mas não vai fazer o envio para o web service. Ele pode ser usado para "simular o processo de envio", mas sua chamada não é necessária, o NFSE_Emitir vai criar o arquivo, assinar, validar ele com os schemas e vai fazer o envio. O link que o @antonio.carlos compartilhou anteriormente vai trazer mais detalhes sobre o processo de envio.

Boa tarde , objetive um retorno do sicoob , por mais que seja informado no campo as informações adicionais ou solicitacaçãoPagador como e realizado via API eles não carregam essa informação para o internet banking deles, quetionei eles porem simplesmente alegam que não carrega essa informações por não ser pix direto, na parte do AcbrPix tudo informado corretamente, obrigado.

https://acbr.sourceforge.io/ACBrLib/ComoemitirumaNFSe.html

No site não está informando sobre qual ntoa técnica se refere. Eu aconselho você a olhar neste link: https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=04BIflQt1aY= É onde estão as notas técnicas com as alterações fiscais. Lá terá esta informação correta, creio que não seria isto que está no post, mas seria melhor dar uma olhada nas notas técnicas para ter certeza.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Olá pessoal! Conferindo às 16h30 do dia 30/06/2025, a notícia publicada no portal do e-Social que originou a criação deste tópico foi removida acessando pelo link: E também não pode mais ser localizada a partir da página inicial de notícias do e-Social:

Olá pessoal! O calendário da aplicação da rejeição de consumo indevido para NFCe pela Sefaz de Minas Gerais foi atualizado novamente para modificar a data para a rejeição 208 e incluir as rejeições 237, 483, 629, 865, 866, 869, 878 e 965 Homologação Produção Regras de Validação 10/03/2025 09/05/2025 539 09/06/2025 16/06/2025 291 e 778 16/06/2025 23/06/2025 204 25/06/2025 30/06/2025 208, 237, 483, 629, 865, 866, 869, 878, 965 Portanto se sua aplicação receber múltiplas vezes em um curto período de tempo as rejeições expostas na tabela nas datas respectivas, você receberá a rejeição de consumo indevido e poderá ser bloqueado de consumir os web services por no mínimo 1 hora.

Olá pessoal! Foi publicada a versão 1.05b desta nota técnica. A nova versão corrige os nomes de alguns campos citados nas regras de validação e nas observações. Alguns exemplos seriam: A observação de pAliqEfet que está usando "pAliqEfet = pIBSUF*(1 – pRedAliq)*(1 - gCompraGov/pRedutor)" foi corrigida para refletir o imposto a que se refere a pAliqEfet em questão. A regra de validação que devolve "400 - Rejeição: Somas dos valores de IBS e CBS em compras governamentais divergente" foi corrigida para "Verificar se a soma dos valores de IBS e CBS do grupo gTribCompraGov (vTribIBSUF + vTribIBSMun + vTribCBS)(...)" As datas permanecem as mesmas da versão anterior e modificações no ACBr não se fazem necessárias. Leia a versão 1.05b na íntegra AQUI.

Olá pessoal! Foi publicada a versão 1.05b desta nota técnica. A nova versão corrige os nomes de alguns campos citados nas regras de validação e nas observações. Alguns exemplos seriam: A observação de pAliqEfet que está usando "pAliqEfet = pIBSUF*(1 – pRedAliq)*(1 - gCompraGov/pRedutor)" foi corrigida para refletir o imposto a que se refere a pAliqEfet em questão. A regra de validação que devolve "400 - Rejeição: Somas dos valores de IBS e CBS em compras governamentais divergente" foi corrigida para "Verificar se a soma dos valores de IBS e CBS do grupo gTribCompraGov (vTribIBSUF + vTribIBSMun + vTribCBS)(...)" As datas permanecem as mesmas da versão anterior e modificações no ACBr não se fazem necessárias. Leia a versão 1.05b na íntegra AQUI.

Olá pessoal! Foi publicado no dia 27/06/2025 a versão 1.06 desta nota técnica. Alterações e Datas A nova versão não traz alterações de leiaute ou regras de validação, apenas altera as datas de entrada em vigor para padronizar com a vigência da NT2025/002. Portanto as novas datas são: Implantação Teste: De 07/07/2025 até 11/08/2025 Implantação Produção: 06/10/2025 Leia a versão 1.06 desta nota técnica na íntegra AQUI.

Olá pessoal! No dia 26/06/2025 foi publicada a versão 1.01 desta nota técnica. Alterações Aumenta o tamanho máximo do campo QrCode para permitir até 1000 caracteres para coincidir com os arquivos de schema já disponibilizados anteriormente. A regra de validação que devolve a mensagem "805 - A SEFAZ do destinatário não permite Contribuinte Isento de Inscrição Estadual" foi atualizada para incluir a lista de UFs conforme texto: Remove a regra de validação que devolve a mensagem "407 - NFC-e com qrCode na versão 3". Datas A nova versão da nota técnica não altera as datas previstas em versão anterior, portanto, permanecem sendo as mesmas. Implantação Teste: Até 02/06/2025 Implantação Produção: Até 01/09/2025 E como fica o ACBr? A nova versão apenas corrige o texto na NT para se adequar ao esquema que já estava correto e foi utilizado como base na implementação feita no ACBr e altera regras de validação, portanto, ajustes nas soluções ACBr não se fazem necessários. Leia a versão 1.01 desta nota técnica na íntegra AQUI.

Para resolver esse problema, você deve reinstalar o PDC Ou seja, execute: ADM -> Manutenção (para apagar a pasta de trabalho) ADM -> Configuração ADM -> Instalação Se não conseguir rodar o TEF, para rodar o comando de Manutenção, você pode apagar a pasta de trabalho, da PayGoWeb

O formato do campo "Data da abertura do DAV" dos registro V2 e V3 e, "Data de geração do arquivo" do registro V4, não estão sendo gerados no formato YYYYMMDD, conforme documentação do PAF-NFC-e. Alteração feita na unit ACBrPAF_V_Class.pas. ACBrPAF_V_Class.pas

Entendendo o problema. O Manifesto Eletrônico de Documentos Fiscais (MDF-e), conforme seu leiaute, permite que sejam referenciados documentos originários. Estes documentos podem ser CT-es, NF-es ou outros MDF-es. Esta é a regra de validação corresponde a esta rejeição de acordo com o MOC Anexo I - Leiaute e as Regras de Validação: Conforme é possível observar, se você está recebendo está rejeição significa que essas informações não foram encontradas no arquivo XML que foi enviado ao web service. Como resolver? Se você utiliza o componente nativo para Delphi/Lazarus, precisa referenciar o documento conforme exemplo: var LManifesto: TManifesto; LInfMunDescarga: TinfMunDescargaCollectionItem; LInfCTe: TinfCTeCollectionItem; LInfCT: TinfCTCollectionItem; LinfNFe: TinfNFeCollectionItem; LInfMDFeTransp: TinfMDFeTranspCollectionItem; LInfUnidTransp: TinfUnidTranspCollectionItem; Lperi: TPeriCollectionItem; begin LManifesto := ACBrMDFe1.Manifestos.Add; LInfMunDescarga := LManifesto.MDFe.infDoc.infMunDescarga.New; //=============>CT-e<============================= LInfCTe := LInfMunDescarga.infCTe.New; LInfCTe.chCTe := ''; LInfCTe.SegCodBarra := ''; LInfCTe.indReentrega := ''; LInfUnidTransp := LInfCTe.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; Lperi := LInfCTe.peri.New; Lperi.nONU := ''; lperi.xNomeAE := ''; Lperi.xClaRisco := ''; Lperi.grEmb := ''; Lperi.qTotProd := ''; Lperi.qVolTipo := ''; LinfCTe.infEntregaParcial.qtdTotal := 0; LinfCTe.infEntregaParcial.qtdParcial := 0; with LinfCTe.infNFePrestParcial.New do chNFe := ''; //=============>CT<============================= LinfCT := LInfMunDescarga.infCT.New; LInfCT.nCT := ''; LInfCT.serie := 0; LinfCT.subser := 0; LinfCT.dEmi := Now; LinfCT.vCarga := 0; LInfUnidTransp := LInfCT.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; //=============>NF-e<============================= LinfNFe := LInfMunDescarga.infNFe.New; LinfNFe.chNFe := ''; LinfNFe.SegCodBarra := ''; LinfNFe.indReentrega := ''; LInfUnidTransp := LInfNFe.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; Lperi := LInfNFe.peri.New; Lperi.nONU := ''; lperi.xNomeAE := ''; Lperi.xClaRisco := ''; Lperi.grEmb := ''; Lperi.qTotProd := ''; Lperi.qVolTipo := ''; //=============>MDF-e<============================= LInfMDFeTransp := LInfMunDescarga.infMDFeTransp.New; LInfMDFeTransp.chMDFe := ''; LInfMDFeTransp.indReentrega := ''; LInfUnidTransp := LInfMDFeTransp.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; Lperi := LInfMDFeTransp.peri.New; Lperi.nONU := ''; lperi.xNomeAE := ''; Lperi.xClaRisco := ''; Lperi.grEmb := ''; Lperi.qTotProd := ''; Lperi.qVolTipo := ''; Caso utilize ACBrMonitorPLUS ou ACBrLib: ; Utilize tags abaixo para Adicionar CTes Relacionados [infCTe001001] chCTe= SegCodBarra= indReentrega= [peri001001001] nONU= xNomeAE= xClaRisco= grEmb= qTotProd= qVolTipo= [infEntregaParcial001001] qtdTotal=0 qtdParcial=0 [infUnidTransp001001001] idUnidTransp= tpUnidTransp= qtdRat= [lacUnidTransp001001001001] nLacre= [infUnidCarga001001001001] idUnidCarga= tpUnidCarga qtdRat= [lacUnidCarga001001001001001] nLacre= ; Utilize tags abaixo para Adicionar NFes Relacionadas [infNFe001001] chNFe= SegCodBarra= indReentrega= [peri001001001] nONU= xNomeAE= xClaRisco= grEmb= qTotProd= qVolTipo= [infUnidTransp001001001] idUnidTransp= tpUnidTransp= qtdRat= [lacUnidTransp001001001001] nLacre= [infUnidCarga001001001001] idUnidCarga= tpUnidCarga qtdRat= [lacUnidCarga001001001001001] nLacre= ; Utilize tags abaixo para Adicionar MDFes Relacionados [infMDFeTransp001001] chMDFe= indReentrega= [peri001001001] nONU= xNomeAE= xClaRisco= grEmb= qTotProd= qVolTipo= [infUnidTransp001001001] idUnidTransp= tpUnidTransp= qtdRat= [lacUnidTransp001001001001] nLacre= [infUnidCarga001001001001] idUnidCarga= tpUnidCarga qtdRat= [lacUnidCarga001001001001001] nLacre= Eu preenchi estas informações, mas mesmo assim elas não foram geradas no meu XML. Para entender isso, primeiro precisamos observar as regras de validação das rejeições 638, 639 e 540: Veja que de acordo com o Tipo do Emitente (tpEmit) que foi preenchido no MDF-e, um determinado tipo de documento não pode ser referenciado. As soluções do ACBr já fazem estas tratativas internamente. Então se, por exemplo, você preencheu o valor 1 para o tpEmit, e preencheu as informações de uma NF-e referenciada, essas informações não serão adicionadas no XML. Você deve corrigir o tpEmit.

Se você usa o novo componente, ACBrTEFAPI, use o método abaixo: function CancelarTransacao( const NSU, // AResp.NSU PWINFO_AUTEXTREF CodigoAutorizacaoTransacao: string; // AResp.CodigoAutorizacaoTransacao PWINFO_AUTHCODE DataHoraTransacao: TDateTime; // AResp.DataHoraTransacaoLocal PWINFO_DATETIME Valor: Double; // AResp.ValorTotal PWINFO_TOTAMNT const CodigoFinalizacao: string = ''; // Parâmetro Opcional, AResp.Finalizacao PWINFO_AUTLOCREF const Rede: string = ''): Boolean; // Parâmetro Opcional, AResp.Rede PWINFO_AUTHSYST