Ir para conteúdo
  • Cadastre-se

Jéter Rabelo Ferreira

Membros
  • Total de ítens

    539
  • Registro em

  • Última visita

  • Days Won

    5

Tudo que Jéter Rabelo Ferreira postou

  1. Sim, a Library Path estava corrigida. Até tenho ela num backup aqui para evitar problemas futuros. Clonei um ACBr do zero hoje, 27/03/2021, para não ter dúvidas e ver se estava 100%. Mas, com o Juliomar parece que o erro não ocorreu. Depois eu efetuo novamente a instalação para ver se ocorre novamente. Atenciosamente.
  2. Bom dia. Baixei um ACBr do zero hoje e refiz a instalação do mesmo. Imagem abaixo. Mesmo problema. Ele adiciona "" no início da Library / Debug / Browsing path e apaga todo o path, deixando apenas o ACBr. EDITADO: ANDROID64 sem problemas (Testei apenas no Sydney - 10.4.2) Atenciosamente
  3. Boa tarde Atualizei meu ACBr dia 15, e hoje fui compilar um App para Android32 e deu erro. Despois de muito procurar o problema, notei que, ao instalar o ACBr, toda a library Path do Android32 foi excluída, ficando apenas as do ACBr. Deixo no início do campo os caracteres ""; . Estou utilizando o Delphi Sidney, mas o problema ocorreu também com o Delphi Rio (Verifiquei). Atenciosamente.
  4. Bom dia. Devido a um problema em MG no dia 25/09, um funcionário de um cliente nosso tentou enviar a nota para Sefaz/MG. Porém nesse dia MG estava com contingência ativa. O erro que retornou ou não retornou o sistema não conseguiu "pegar". Pois isso é tratando para que não ocorra. Porém, a pessoa, em vez de efetuar a consulta, mudou para contingência e autorizou a nota. Mas a mesma NF-e foi autorizada em MG. Então temos a mesma NF-e autorizada em MG e no ambiente de contingência nacional. Alguém sabe como proceder num caso desses? Atenciosamente.
  5. Bom dia. Ainda não foi incluído no ACBr o Bradesco. Os fontes, conforme dito anteriormente, estão disponíveis (doados) para a referida inclusão caso alguém deseje fazer. Obs.: Está em produção há quase 2 anos em clientes nossos. Atenciosamente.
  6. Boa tarde. Bradesco nós desenvolvemos há meses e está em produção desde então. Na época eu enviei um post oferecendo os fontes, mas não aceitaram. Segue abaixo o link da unit, eu liberei o código. https://bitbucket.org/jerasoft/jera-da-di/src/master/ Se quiserem adaptar para os moldes do ACBr, sem nenhum problema. Obs.: Nesse mesmo link acima, tem também para débito automático. Em produção Bradesco e Itaú. Caixa em Homologação. Depósito identificado: Bradesco e Itaú, Atenciosamente.
  7. Bom dia. Estava com esse problemas meses atrás, fui verificar e era o arquivo INI que estava errado. Eu enviei o mesmo arquivo e o problema acabou. Arquivo NFSeBrasil.ini Verifique as tag's conforme abaixo: [Remover] ; 0 = Não / 1 = Sim QuebradeLinhaRetorno=1 EComercial=1 Tabulacao=1 TagQuebradeLinhaUnica=1 EComercial no meu caso estava como 0. Nunca mais tivemos problemas Atenciosamente.
  8. Sim, isso pode ser feito, com certeza. Eu apenas retirei os demais Campos pois a tag é descrição do serviço. Atenciosamente
  9. E um detalhe, se algum usuário já alterou o XML antes de imprimir não ocorrerá nenhum problema, pois foi tratado isso.
  10. Essas informações para a impressão do Danfse são totalmente desnecessária. isso não altera o XML do usuário
  11. Atual Após correção Tag do XML encontra dessa forma Esses campos que estão informados, fora a descrição, já existem na NFS-e Atenciosamente
  12. Bom dia. Temos um cliente faz a geração de NFS-e para o provedor Betha há muitos anos. Porém, a quantidade de NFS-e era baixa, por volta de umas 400/mês. Nunca prestamos atenção como o XML do referido provedor devolvia a descrição. Mas, devido a algumas modificações no regime tributário e fiscal da empresa, migramos a emissão de alguns documentos para ISSQN. Serão mais de 100.000 NFS-e por mês Aí hoje o diretor me ligou questionando quanto a esse campo. Fui ver, e tinha vários tópicos aqui dessa solicitação, mas sem solução. Eu efetuei pequenas modificações no código fonte do Fortes e Fast para "limpar" esse campo somente quando o provedor for Betha, deixando apenas o campo descrição para a impressão. Seguem anexas as duas unit's para análise de vocês. Atenciosamente. ACBrNFSeDANFSeFR.pas ACBrNFSeDANFSeRLRetrato.pas
  13. Boa tarde. Encontrei um problema ao exportar NFS-e para PDF. O componente não estava conseguindo montar o nome do arquivo quando não informado. Método "TACBrNFSeDANFSeFR.ImprimirDANFSePDF(NFSe: TNFSe);" Bastou retirar o WITH que o problema resolveu. (O delphi estava se perdendo entre o parâmetro do método e o WITH - NFSe). Segue unit corrigida. Atenciosamente. ACBrNFSeDANFSeFR.pas
  14. @Daniel Simoes, achei o problema. Na unit ssl_openssl_lib tem um array com os nomes das DLL's, e ela tem uma diretiva CPU64, mas o correto é WIN64. Devido a esse problema, ao buscar os nomes das DLL's, ele sempre trazia o nome da lib de 32 bit's, e nunca a de 64. Efetuei a mudança, recompilei o projeto e funcionou. Segue a unit alterada. Atenciosamente.ssl_openssl_lib.pas
  15. @Daniel Simoes, o interessante é na minha máquina com Delphi funciona também. Mas o exemplo que eu te passei ontem foi no server de um cliente nosso, Windows Server 2016, onde tem somente nosso sistema instalado e o Banco de Dados, nada mais. Esse mesmo ocorreu em 2 clientes diferentes. E, como demonstrado, somente na versão x64 do programa. Mas, eu já adaptei o setup para enviar/instalar as DLL's (MINGW) somente na versão x64 do Windows. A versão x32 do Windows não é enviada/instalada. Dessa forma, não teremos mais ligações aqui no suporte, até que eu possa analisar mais a fundo o que pode estar ocorrendo. Atenciosamente.
  16. Daniel, vamos lá. Compilei o exemplo em x32 e x64 e solicitei uma consulta simples de status do serviço (Utilizei MG, mas o erro independe). Como você pode ver na imagem abaixo (Imagem Sem Titulo1.jpg): x32 - OK - (Temos XML de resposta da consulta) X64 - ERRO (Mensagem de não suportar TLS1.2 (O mesmo erro reportado por mim em post anterior)) Após encontrar erro, coloquei todas as dll's da pasta do MINGW x64 na pasta do programa e, voilá, consulta efetuada com sucesso! (Imagem Sem Titulo2.jpg) Acho que consegui explicar o problema. Lembrando que essa instalação é 100% limpa Atenciosamente.
  17. Eu apaguei todo o meu repositório e clonei um totalmente novo (veja datas na imagem abaixo), Foi como eu disse. x32 - OK x64 - Não (Sem as DLL's OpenSSL com nomenclatura antiga - ssleay32 e etc). Eu coloquei as MINGW e funcionou. Obs.: A pasta fontes está informada como alterada é o ACBr.inc alterado para retirar as opções (Capicom, XMLSec e etc)
  18. Seguinte. Atualizei o componente e o erro foi o mesmo, precisando das DLL's MINGW para consultar uma NF-e. Porém, ao utilizar a versão x32 do programa funcionou somente com as DLL's OpenSSL e Libxml2. O erro ocorre somente com a versão x64 do programa.
  19. Veja imagem do meu ACBr.inc quanto a MINGW Vou clonar um repositório totalmente novo e instalar e testar. Depois informo o resultado. Atenciosamente.
  20. Sim, a imagem está em LT_all. Mas eu mudei no sistema para LT_TLS1_2 e o erro ficou igual, mas informando que não suporta LT_TLS1_2 (Somente não colei a imagem). Fontes atualizados nessa semana. Vou atualizar novamente para verificar. "Obs.: Como disse acima, bastou colar as DLL's do MINGW que Notas foram autorizadas." Atenciosamente.
  21. Bom dia. Estou com um problema semelhante. Passei a enviar somente as DLL's OpenSSL (1.1.1) e libxml2 e versão x64 de um de nossos sistemas. Hoje um cliente me reportou o erro (imagem abaixo). Mudei para TLS1.2, e erro mudou para não suporte LT_TLS1_2. Peguei as DLL's do MINGW e colei na pasta e funcionou. Minha instalação não exige MINGW (Antigamente utilizava). Como resolver isso para não precisar dessas DLL's (MINGW -x32/x64)?
  22. Boa tarde. Fui implementar a impressão de Inutilização de Documento fiscal (Delphi) e ocorreu memoryLeak. Fui analisar, faltavam duas coisas. Efetuar o Free no ClientDataset (cdsItens) e vincular o evento FormDestroy ao Form. Segue a unit corrigida. (Abri o tópico no fórum errado. O correto é CTe) Atenciosamente. ACBrCTeDAInutRL.pas ACBrCTeDAInutRL.dfm
  23. Bom dia. Ao importar o XML para o sistema efetuamos a "limpeza" dos pontos nas TAG's de valores. Como esses XML's não possuem um DigestValue para validação, não tem problema quanto a isso. Atenciosamente.
  24. Boa noite Efetuamos o tratamento interno mesmo. Podem desconsiderar esse post. Atenciosamente.
  25. Boa tarde. Estamos com um problema na NFS-e do provedor NFSeBrasil. Valores acima de 1.000,00 vem formatados, conforme pode ser visto no XML anexo (e imagem abaixo). Gostaria de saber como fazer para corrigirmos isso, pois a rotina de conversão é feita na unit ACBrUtil, o que pode afetar outras coisas. Ao passar por ela, ele transforma o primeiro pronto para vírgula, e quando vai fazer o StrToFloat gera uma exception, retornando o valor zerado. Atenciosamente. 20202-nfse.xml
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.