Painel de líderes

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! Muitas vezes, quando precisamos expor um problema no fórum para pedir ajuda aos demais membros da comunidade, anexamos imagens e arquivos para melhorar ilustrar a situação e também ajudar na análise e nos testes. No entanto, pode ter vezes em que o fórum não permita que seu arquivo ou sua imagem sejam adicionados na postagem. Um dos motivos para isso acontecer é o limite de anexos do seu usuário no fórum estar próximo do tamanho máximo permitido. Mas nem tudo está perdido! É muito simples de limpar alguns anexos antigos para abrir espaço para novos. Vamos a um passo a passo. 1º Clique no seu usuário no canto superior direito do fórum e depois clique em "Meus Anexos". 2º Ele vai abrir uma página para você informando quanto de espaço já foi utilizado, quanto ainda tem livre e uma lista com todos os seus anexos. 3º Basta selecionar um anexo nessa lista que ele automaticamente vai lhe dar uma opção para que você possa excluir o mesmo e liberar mais espaço. Mas eu fiz isso e ainda assim da erro, o que pode ser? O Fórum do Projeto ACBr tem certas proteções ativadas para evitar ataques. Um desses tipos de ataques é o de SQLInjection, no qual o infrator tenta forçar a execução de uma query ou código malicioso. Se mesmo depois de liberar espaço, você ainda recebe um erro como este ao tentar anexar um arquivo: É possível que uma parte do que esteja tentando anexar esteja sendo barrada por essa medida de proteção. Uma sugestão neste caso, é zipar o(s) arquivo(s) ao invés de tentar anexar eles diretamente.

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica , é possível observar que a Sefaz de Minas Gerais está com contingência agendada para o dia 10/12/2023. Com previsão de inicio às 05h00 e término às 10h00 do mesmo dia. Para usar o ACBr em contingência durante este período, siga as orientações deste tópico: Um agradecimento aos membros da comunidade que chamara atenção ao fato no canal #sefaz em nossa comunidade do Discord.

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=

Movi para a comunidade aberta para que mais membros possam interagir com sugestões e opiniões.

Bom dia, Também sempre ligo para o suporte da IPM, e falo como o Douglas, que foi o responsavel pela implantação in loco em Pinhais. O que eu questionei era que antes tinha um URL, que esta no manual, (destaquei em vermelho) que sempre funcionou. Em contato com ele, me passou a nova (destaque em verde) a qual mudei e funcionou perfeitamente, meus clientes estão emitindo sem problema NFSe em Pinhais-PR. Da forma que esta no ACBr esta funcionando.

Problema Resolvido

Bom dia @softwareamigo seu Delphi é CE ? Caso positivo, pode ser por isso

Boa noite, Obrigado pela contribuição. Foram enviadas correções ao SVN que devem resolver o problema relatado, Rev-31479 Por favor atualize os fontes, reinstale os componentes, verifique se o problema foi resolvido e, se possível, nos informe se foi o resultado esperado.

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.

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

Só para dar um feedback e compartilhar com quem interessar... Usando o CTe 4.00 o retorno trás a chave de acesso da nf-e. No entanto, pelo menos em SP, o retorno trás sempre a chave da última nf-e referenciada, mesmo estando válida, e não a chave da primeira nf-e com situação inválida, que seria o correto conforme descreve o MOC. Não sei se mais alguem percebeu isso. Enviei mensagem para o sefaz-sp explicando o caso estou aguardando resposta.

Boa noite, O componente foi atualizado hoje. Atualize novamente e veja se não tem nenhuma alteração local, pois tem que funcionar e confirme se não tem uma cópia do ACBrNFSeXServicos.ini na pasta do seu exe. Se você ainda utiliza a versão antiga do componente, ela não recebe mais atualizações a mais de 2 anos, migre para o ACBrNFSeX.

Olá pessoal, Foi publicado a versão 1.30 da NT 2021/003 que trata das Validações do GTIN. "A versão 1.30 da NT basicamente amplia o grupo de NCM (grupo de Mercadorias) que verificam a existência do GTIN no CCG-Cadastro Centralizado de GTIN, dando continuidade a ampliação da obrigatoriedade de uso para indústrias donas de marcas." Essa NT se refere ao Grupo III Observação: Como se trata de validação de novos NCM por parte da SEFAZ não se faz necessário nenhuma alteração no componente ou Lib ou Monitor e nem na sua aplicação. Lembrando que os NCM listados no grupo III tem que estar com os GTIN corretos no cadastro de itens de produtos nos seus clientes, caso contrario a nota vai ser rejeitada.

Olá pessoal! Entre os dias 04 e 05 tivemos relatos em nossa comunidade do Discord de problemas para emitir CT-e para a Sefaz São Paulo, com o número de protocolo de CT-es autorizados sendo devolvido com tamanho 16 ao invés de 15. Considerando os últimos relatos, tudo indica que a situação foi normalizada e a resposta da Sefaz está de acordo com a documentação. Segue abaixo uma breve transcrição do ocorrido. Se você ainda está tendo problemas, é importante que deixe a Sefaz ciente através de um Fale Conosco. Os primeiros relatos começaram no dia 04/12/2023, por volta das 08h52 e informavam que a emissão era feita com sucesso, mas a Sefaz estava devolvendo um número de protocolo com 16 dígitos ao invés de 15 que é o tamanho estipulado, causando assim problemas. Por volta das 15h49, membros começaram então a reportar estarem recebendo no retorno: Durante este mesmo período, alguns membros mencionaram ter conseguido emitir CT-e enviando em contingência e nesses casos o número do protocolo devolvido era composto de 15 caracteres. No dia 05/12/2023, por volta das 08h46, participantes da comunidade cujos clientes emitiram CT-es em modo normal e receberam um número de protocolo com 16 dígitos estavam tendo dificuldades para realizar o cancelamento devido ao tamanho atípico. Outro detalhe que foi notado é o fato desses CT-es de 16 dígitos estarem retornando 01/01/0001 00:00 na informação da data/hora de aprovação ao realizar um consulta. Por volta das 14h00, tivemos relatos de sucesso ao cancelar os CT-es removendo o primeiro número do protocolo de 16 posições normatizando para o tamanho esperado de 15. A conclusão que se chegou por parte dos integrantes da comunidade é a de que o contador do campo do protocolo estourou passando então para 16 caracteres. As 15h02, um membro relatou que ao consultar as chaves dos CT-es que devolveram protocolo com 16 dígitos, a informação havia sido corrigida e o campo estava agora com caracteres. Não foi encontrado comunicado oficial a respeito do ocorrido no Portal Estadual durante o período.

Boa tarde a todos do Fórum, solução para o problema mencionado a cima, gostaria de compartilhar. Obs: Este problema ocorreu comigo após atualização de Versão do Delphi 10 Seattle para o Delphi Berlin, depois removi a versão do Berlin achando que pudesse ser ele o causador do problema. Mesmo copiando a midas.dll do repositório C:\Program Files (x86)\Embarcadero\Studio\17.0\Redist\win32\midas.dll (428kb 12/11/2015) para o "C:\Windows\SysWOW64\" e registrando não funcionou de forma alguma. Pesquisei bastante e encontrei esta versão do midas.dll anexa mais recente (425kb 12/10/2016), fiz o procedimento abaixo e agora está funcionando perfeitamente. Copie o arquivo anexo para "C:\Windows\SysWOW64\" Execute o "CMD como administrador". Cole o seguinte comando na janela da Linha de comando que se abre e pressione a tecla Enter. % Windir% \ System32 \ regsvr32.exe midas.dll e% windir% \ SysWoW64 \ regsvr32.exe midas.dll Obrigado a todos, meu problema está resolvido. midas.dll