Painel de líderes

Crie um stream e passa para a impressão, depois manipule o stream como tu precisar... por exemplo : LMeuStream := TMemoryStream.Create; try ACBrNFSeX1.NotasFiscais.ImprimirPDF(LMeuStream); LMeuStream.SaveToFile('C:\tmp\meupdf.pdf'); finally LMeuStream.Free; end;

Olá pessoal! No dia 09/11/2023 foi publicada no Diário Oficial da Secretaria da Fazenda do Rio de Janeiro, dentre outras a resolução Nº578 de Novembro de 2023. Essa resolução além de trazer orientações sobre como o contribuinte deve preencher o SPED, trás também os Art. 16-E e 16-F que orientam na obrigatoriedade do preenchimento dos campos de ICMS Efetivo e Retido e cujo texto transcreve: A resolução entrou em vigor na data de publicação e seus efeitos passarão a valer a partir de 01/01/2024. Como preencher estas tags no ACBr? Se você utiliza o componente ACBrNFe nativo para Delphi e Lazarus, as tags são alimentadas pelas propriedades: ACBrNFe.NotasFiscais[Indice].NFe.Det[OutroIndice].Imposto.ICMS.vBCSTRet := ACBrNFe.NotasFiscais[Indice].NFe.Det[OutroIndice].Imposto.ICMS.vICMSSubstituto := ACBrNFe.NotasFiscais[Indice].NFe.Det[OutroIndice].Imposto.ICMS.vICMSSTRet := ACBrNFe.NotasFiscais[Indice].NFe.Det[OutroIndice].Imposto.ICMS.vBCEfet := ACBrNFe.NotasFiscais[Indice].NFe.Det[OutroIndice].Imposto.ICMS.pICMSEfet := ACBrNFe.NotasFiscais[Indice].NFe.Det[Outroindice].Imposto.ICMS.vICMSEfet := Agora caso utilize o ACBrMonitor ou a Lib que recebem um arquivo INI, os campos são: [ICMSXXX] vBCSTRet= vICMSSubstituto= vICMSSTRet= vBCEfet= pICMSEfet= vICMSEfet=

Publicada a versão 3.1.6 do Guia Prático do EFD ICMS IPI A nova versão foi publicada no dia 04/12/2023, com vigência a partir de janeiro de 2024 e trás as seguintes alterações: Fonte: http://sped.rfb.gov.br/pagina/show/7290 Como podem ver, será necessário alterações no componente ACBrSPEDFiscal. Ficamos felizes com o apoio de todos que puderem nos ajudar com contribuições

Efetuei o teste, mesmo retorno. Anexei o log do teste. Lembrando que esta prefeitura atualizou se não engano no início do ano, a conexão de HTTP para HTTPS. ACBrLibNFSe-20231207.log

Claro, irei testar !

Encontrei a solucção, Abra as configurações do seu navegador padrão, acesse opçoes de internet /privacidade/avançado/bloquear cookies(interno e de terceiros). Devido aos cookies ele mantem a sessão com login e senha do provedor. Por isso ocorre a rejeição. Ele mantem as credenciais do primeiro envio salvo. bloqueei os cookies e deu certo.

Boa tarde a todos, Estava obtendo erro ao enviar o evento S-2240 e notei que tem 2 erros na linha 591 da unit ACBreSocial\PCNeSocial\pcesS2240.pas. Detectei 2 erros nesta linha: 1- Conforme o layout data inicial da tag dtFimCondicao é 16/01/2023 e está como 16/01/2022; 2-Na condição DateToStr(objInfoExpRisco.dtFimCondicao) <> dDataBrancoNula), no meu caso a função DateToStr retorna '30/12/99' enquanto a constante dDataBrancoNula = '30.12.1899' Acertei trocando a linha para essa: if ((objInfoExpRisco.dtIniCondicao >= StringToDateTime('16/01/2023')) and (objInfoExpRisco.dtFimCondicao > 0)) then Abraço!

Notamos vários relatos, de usuários que não estavam conseguindo carregar alguns certificados, usando a versão 3.x.x do OpenSSL, e sendo que esse mesmo certificado, é carregado normalmente, na versão 1.1.x do OpenSSL Ocorre que a versão 3.x do OpenSSL, tornou "legado" algumas rotinas de criptografia... E provavelmente os certificados que causavam erro, estavam usando essas rotinas legadas... Esse link nos ajudou com a solução que aplicamos nos fontes do ACBr, e dá mais detalhes sobre o problema: https://github.com/openssl/openssl/issues/19368 A modificação que aplicamos depende que o OpenSSL consiga carregar a biblioteca "legacy", portanto a mesma deve estar na mesma pasta das demais... Você pode ver as modificações, nesse histórico de Commit [r31480] Essa biblioteca "legacy.dll" agora é distribuída na pasta: ACBr\DLLs\OpenSSL\3.1.3\x64 Observe que não encontramos uma distribuição do OpenSSL, que tenha a "legacy.dll" para 32 bits... portanto, a carga dessa DLL, no Windows, só irá funcionar, se você estiver compilando o seu executável em 64 bits... Abaixo estão algumas dicas, se você estiver com problemas ao ler o Certificado, usando OpenSSL 3 Verifique se a biblioteca "legacy" está na mesma pasta das demais DLLs do OpenSSL 3 - Lembrando que conforme explicamos acima, ela está disponível, apenas para 64 bits - A pasta com todas as DLLs ficaria algo como: "libcrypto-3-x64.dll, libssl-3-x64.dll, legacy.dll" - Você não conseguirá usar as bibliotecas de 64 bits, se estiver compilando a sua aplicação em 32 bits Instale o certificado no Windows, e Exporte ele novamente Isso fará com que o Windows reescreva o certificado, utilizando rotinas de criptografia mais modernas, e com isso, permitindo o uso dele no OpenSSL 3.x Volte para versão 1.1.x.x do OpenSSL... Essa versão da biblioteca OpenSSL provavelmente continuará sendo utilizada, por muitos e muitos anos

Olá pessoal. Foi publicado no dia 04/12/2023 notícia na Sefaz da Paraíba informando que a partir de Janeiro de 2024 a escrituração do registro 1601 no EFD, que havia sido prorrogada anteriormente atendendo a pedidos de entidades do setor, passará a ser obrigatória. O registro 1601 na Escrituração Digital Fiscal identifica o valor total das operações realizadas pelo declarante por meios de pagamento eletrônico, discriminando por instituição financeira e de pagamento, fazendo elas parte ou não do Sistema de Pagamentos Brasileiro.

Por favor, consegue testar com a versão de gramado em taquara e nos reportar ?

Bom dia ! E com o provedor de Gramado que vc tem em produção o erro não acontece ? Utiliza a mesma versão da lib neste provedor tbm?

Obrigado pelo feedback @Daniel Simoes! Estamos com um prazo um pouco apertado para conclusão desta demanda, porém assim que minha pauta dispor de tempo hábil eu posso tentar contribuir de alguma forma. Abraços!