Ir para conteúdo
  • Cadastre-se

DatawebDev

Membros Pro
  • Total de ítens

    46
  • Registro em

  • Última visita

  • Days Won

    1

Tudo que DatawebDev postou

  1. Prezados, na alteração que propus, as units não foram adicionadas nos pacotes DCL*.pas (design time), e sim nos pacotes que estes dependem (requires). Esse design pattern é usado em outros pacotes do projeto, e foi por isso que segui. Exceto pela unit ACBr*Reg, as demais units ficam no contains do pacote ACBr_*.dpk, e a única unit no contains do pacote DCLACBr_*.dpk é a ACBr*Reg. O pacote ACBr_*.dpk fica no requires do pacote DCLACBr_*.dpk, e assim o pacote de design time tem acesso as demais units que estão no contains do pacote que não é de design time.
  2. Uses e contains são coisas diferentes. A unit ACBrTEFAndroid não pode estar no contains de dois packages, mas pode estar no uses de diversas outras units. O package DCLACBr_TEFD depende (requires) do package ACBr_TEFD, e a unit ACBrTEFDReg contida (contains) no DCLACBr_TEFD usa (uses) uma unit contida (contains) no package ACBr_TEFD. Podem ser pacotes que já estão em desuso, mas estão quebrando nosso processo de build aqui. Estamos migrando para o Delphi Rio, e a compilação do ACBr tranca por causa desses dois pacotes. Com as correções do primeiro comentário, o ACBr compila no nosso ambiente.
  3. Obrigado pela resposta Juliomar. Entendo que os componentes já estejam descontinuados ou defasados, mas se seus códigos fonte ainda fazem parte do repositório, deveríamos deixá-los compilando, certo? Abaixo a linha de comando que utilizei para reproduzir o problema com o pacote ACBr_NFSe, e em anexo o resultado com o erro. Acontece o mesmo com o outro pacote. Depois que adicionei as units que faltavam, nos arquivos DPK adicionados na abertura do tópico, os erros foram resolvidos. C:\Program Files (x86)\Embarcadero\Studio\20.0\bin\dcc32.exe ACBr_NFSe.dpk -$D- -$L- -$Y- -B -Z -DRELEASE -LEC:\Users\Public\Documents\Embarcadero\Studio\20.0\Bpl -LNC:\Users\Public\Documents\Embarcadero\Studio\20.0\Dcp -N0C:\Projetos\Components\ACBr\library\Win32 -IC:\Projetos\Components\ACBr\Fontes\ACBrComum;C:\Projetos\Components\ACBr\Fontes\ACBrDiversos;C:\Projetos\Components\ACBr\Fontes\ACBrOpenSSL;C:\Projetos\Components\ACBr\Fontes\ACBrSerial;C:\Projetos\Components\ACBr\Fontes\ACBrTCP;C:\Projetos\Components\ACBr\Fontes\Terceiros\CodeGear;C:\Projetos\Components\ACBr\Fontes\Terceiros\GZIPUtils;C:\Projetos\Components\ACBr\Fontes\Terceiros\json4delphi\src;C:\Projetos\Components\ACBr\Fontes\Terceiros\JsonDataObjects\Source -UC:\Projetos\Components\ACBr\Fontes\ACBrComum;C:\Projetos\Components\ACBr\Fontes\ACBrDiversos;C:\Projetos\Components\ACBr\Fontes\ACBrOpenSSL;C:\Projetos\Components\ACBr\Fontes\ACBrSerial;C:\Projetos\Components\ACBr\Fontes\ACBrTCP;C:\Projetos\Components\ACBr\Fontes\Terceiros\CodeGear;C:\Projetos\Components\ACBr\Fontes\Terceiros\GZIPUtils;C:\Projetos\Components\ACBr\Fontes\Terceiros\json4delphi\src;C:\Projetos\Components\ACBr\Fontes\Terceiros\JsonDataObjects\Source -RC:\Projetos\Components\ACBr\Fontes\ACBrComum;C:\Projetos\Components\ACBr\Fontes\ACBrDiversos;C:\Projetos\Components\ACBr\Fontes\ACBrOpenSSL;C:\Projetos\Components\ACBr\Fontes\ACBrSerial;C:\Projetos\Components\ACBr\Fontes\ACBrTCP;C:\Projetos\Components\ACBr\Fontes\Terceiros\CodeGear;C:\Projetos\Components\ACBr\Fontes\Terceiros\GZIPUtils;C:\Projetos\Components\ACBr\Fontes\Terceiros\json4delphi\src;C:\Projetos\Components\ACBr\Fontes\Terceiros\JsonDataObjects\Source -NSSystem;System.Win;WinAPI;Vcl;Vcl.Imaging;Vcl.Samples;Vcl.Shell;Data;Data.Win;DataSnap;Xml;Soap;VCLTee;FIBX;Bde;Web dcc32_output_acbr.txt
  4. Faltou incluir algumas units em ACBr_NFSe.dpk e ACBr_TEFD.dpk. Compilador de linha de comando do Delphi Rio reclamou que não as encontrava. Em anexo os arquivos DPK corrigidos. Favor incorporar as alterações no SVN para podermos concluir a atualização do ACBr aqui no ambiente de dev. ACBr_NFSe.dpk ACBr_TEFD.dpk
  5. Desculpa não ter deixado claro, mas eu ocultei propositalmente. O XML da NFSe foi retornado corretamente na propriedade do JSON. Retorna vazio, como descrito aqui: Estamos com outro problema agora, onde a NFSe retorna ISSQN em homologação, e não retorna em produção, mesmo com os DPS sendo preenchidos com os mesmos valores nos dois ambientes. Não quero misturar esse problema aqui no tópico do retorno vazio, e preferiria tentar o suporte do Ambiente Nacional antes de abrir outro tópico para tratar disso - nem vejo como algo relacionado ao ACBrNFSeX. Alguém poderia me passar os canais de suporte ao desenvolvedor do Ambiente Nacional? Busquei no site oficial, mas não encontrei. Quero ver com eles o problema deste tópico aqui, e o outro problema de retornar ISSQN somente em homologação.
  6. As rotinas de emissão são idênticas, só mudou a série e número de DPS (homologação) usados nos sistemas. No ambiente que conseguia emitir, era usada a série 6, e numeração começando de zero. No ambiente que não conseguia emitir (resposta sem erro nem XML), era usada a série 1, e a numeração continuava com a sequência usada em produção pelo cliente. Aparentemente, o DPS de número 1702 deste cliente está com algum problema no serviço do ambiente nacional em homologação. Incrementamos para o próximo número de DPS (1703) e conseguimos retomar as emissões. Abaixo a resposta da emissão do DPS 1703, contendo os mesmos valores dos campos do DPS 1702: { "tipoAmbiente": 2, "versaoAplicativo": "SefinNac_Pre_1.0.0", "dataHoraProcessamento": "2023-12-18T19:55:47.1381257-03:00", "idDps": "NFS43149022211111111111111000000000000623120123893478", "chaveAcesso": "43149022211111111111111000000000000623120123893478", "nfseXmlGZipB64": "[...]", "alertas": null } Assim como fiz anteriormente, editei o idDPS e a chave de acesso da mensagem para ocultar o CNPJ do emissor. Como fazemos para investigar o problema desse DPS com o suporte do Ambiente Nacional de NFSe?
  7. Desculpem pela demora na resposta. @Daniel InfoCotidiano e @Diego Foliene muito obrigado pelas respostas! Fiz a consulta por DPS, e retornou o erro abaixo: Erro na NFSe: Código: X999 Descrição: Erro de Conexão: Erro Interno: 0 Erro HTTP: 500 URL: https://sefin.producaorestrita.nfse.gov.br/SefinNacional/dps/431490221111111111111100001000000000001702 WebService retornou um XML vazio. Assim como fiz anteriormente, editei o idDPS da mensagem para ocultar o CNPJ do emissor. Enquanto investigava esse problema, consegui emitir NFSe com o mesmo emissor, mas usando nosso sistema de testes de integração. Agora estou comparando ambos os sistemas para identificar a diferença (usam a mesma versão do ACBr), e descobrir em qual situação que o DPS é enviado pelo ACBrNFSeX, e retorna sem erros e sem NFSe. Atualizo aqui quando descobrir.
  8. Prezados, boa noite. Estamos testando emissão de NFSe em homologação, no ambiente nacional, para Porto Alegre/RS. Trecho do ACBrNFSeXServicos.ini: [4314902] Nome=Porto Alegre UF=RS Provedor=PadraoNacional Nas primeiras tentativas, a API retornou alguns erros de preenchimento do DPS, que corrigimos. Agora está retornando sem erros, mas também sem NFSe, como se pode ver no arquivo 305354-lista-nfse-ger.json em anexo, ou no seu conteúdo abaixo: { "tipoAmbiente": 2, "versaoAplicativo": "SefinNac_Pre_1.0.0", "dataHoraProcessamento": "2023-12-14T19:28:56.39864-03:00", "idDPS": "DPS431490221111111111111100001000000000001702", "erros": [] } Anexo também o XML do DPS. Em ambos os anexos, editei informações sensíveis do emitente/prestador e do tomador. Já viram esse problema no ambiente nacional? Poderiam nos ajudar? 305354-lista-nfse-ger.json 17021-rps.xml
  9. Funcionou! Muito obrigado Italo! Desculpe a demora na resposta aqui, mas encontrei um problema no tratamento de retorno de "lote em processamento" desse provedor, testando envio assíncrono de lote de RPS. Não consegui entender o problema exatamente, mas parece que a resposta da consulta de situação está retornando sucesso, mesmo quando retorna com erros - situação que deveria ser tratada como insucesso, pelo código do provedor. Analisarei detalhadamente esse caso da resposta, e se o problema for no provedor, eu tento corrigir e abro um novo tópico específico.
  10. Boa noite Italo. Bem lembrado! Me recordo desse tratamento em alguns provedores. Testei a tua solução e funcionou, segue em anexo. Muito obrigado pela solução! Dessa forma já atende a nossa necessidade, então se puderem incorporar no SVN, agradecemos. Betha.GravarXml.pas
  11. Prezados, boa noite. O serializador XML do ACBrNFSeX, para o provedor Betha, não gera as tags Aliquota, BaseCalculo e ValorIss, quando o valor destas é zero. Por causa disso, os RPS nessa situação são rejeitados com a mensagem de retorno abaixo: <MensagemRetorno> <Codigo>E163</Codigo> <Mensagem>Alíquota não informada para retenção do ISSQN no Simples Nacional.</Mensagem> <Correcao>Informe um percentual de acordo com o enquadramento na tabela de alíquota do simples nacional.</Correcao> </MensagemRetorno> Para não impactar todos os municípios que usam Betha, criei params para configurar a geração das tags somente no município que precisar. Alterei TNFSeW_Betha.Configuracao, para tratar três valores para o param GerarTag: Aliquota, BaseCalculo e ValorIss. Depois incluí esse GerarTag no Params do ACBrNFSeXServicos.ini do município: Params=GerarTag:Aliquota,BaseCalculo,ValorIss Em anexo os dois arquivos alterados. Poderiam incorporar as alterações no SVN, por gentileza? Betha.GravarXml.pas ACBrNFSeXServicos.ini
  12. Bom dia Daniel! Tua dica resolveu o problema, muito obrigado! Testei com o ACBrNFe_Exemplo, que assim como a minha aplicação, usa o valor padrão de 1000ms na propriedade TACBrNFe.Configuracoes.WebServices.IntervaloTentativas. Aumentei para os 5s recomendados na postagem do Diego, e em conjunto com as outras propriedades da postagem, não aconteceu mais o "erro" de Lote em processamento. Bom dia Diego! Muito obrigado pelas orientações e pela postagem do dia 17 de fevereiro, muito esclarecedora!
  13. Prezados, boa noite. Usando o ACBrNFe_Exemplo, eu tentei autorizar uma NFe em homologação na SEFAZ GO, com envio assíncrono, pelo botão Criar e Enviar. Retornou o erro Lote em processamento (cStat 105). Depois de alguns minutos eu consultei o lote novamente, pelo botão Consultar Recibo Lote, e retornou o lote processado (cStat 104) - e rejeitado, mas não deve ser relevante para esse problema. Em anexo os arquivos XML de comunicação, da criação e envio, e também da consulta posterior. Tenho o mesmo problema na nossa aplicação que usa o ACBrNFe, no ambiente de homologação de Goiás. Já passaram por esse problema?
  14. Obrigado pela resposta Renato. Sim, SSLType continua com LT_TLSv1_2, como na primeira imagem. Testei agora com timeout de 30k e deu o mesmo erro de falha no handshake. Em nenhuma máquina daqui eu consigo comunicar com a SEFAZ-GO usando o certificado digital desse cliente com a OpenSSL (independente da versão). Na máquina de dev (Win8.1) eu não consigo comunicar com a SEFAZ-GO nem usando WinCrypt (crypt32.dll v6.3.9600.16431). Mas em máquina com Win10 eu consigo comunicar usando a WinCrypt (crypt32.dll v10.0.19041.2486) e com esse certificado digital do cliente. Aguardarei a permissão do cliente para que possa enviar o certificado digital ao Daniel, para investigarmos esse problema do cert. com OpenSSL.
  15. Testei com a versão 1.1.1.20 do OpenSSL, mas o resultado foi o mesmo. Muito obrigado pela ajuda Daniel! Pedirei permissão para o nosso cliente, dono do certificado, e ele permitindo, já te envio por mensagem privada.
  16. Daniel, o problema persiste no teu ACBrNFe_Exemplo. As DLL do OpenSSL que acompanham ele são da mesma versão (1.1.1.10) que eu estava usando.
  17. Muito obrigado Daniel! Testarei agora mesmo, e reporto resultado em seguida.
  18. Oi Daniel. A versão do OpenSSL é a 1.1.1j distribuída pelo ACBr. Está na minha primeira imagem, e última resposta nesse tópico. De onde posso pegar essa 1.1.1o que tu estás usando? Foi compilada por ti mesmo?
  19. Obrigado pela resposta Juliomar. A versão do OpenSSL é a mais recente das 1.1.1 disponível no repo do ACBr: 1.1.1j, conforme aparece nas imagens da postagem original. Testei também com a 1.0.2.21 e o erro foi o mesmo.
  20. Prezados, boa noite. Temos um cliente que consegue comunicar com o ambiente de produção da SEFAZ GO, usando seu certificado digital, e com o ACBrNFe configurado para usar OpenSSL e TLS1.2. Mas no ambiente de homologação, com os mesmos dados, OpenSSL dá erro de SSL (alert handshake failure). Testamos também usando WinCrypt+WinHttp, e dá erro de SSL também (... erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor). Conseguimos reproduzir o problema no ACBrNFe_Exemplo: Ainda usando WinCrypt, quando alteramos SSLType de LT_TLSV1_2 para LT_all, SEFAZ GO retorna erro reclamando da versão de TLS usada (abaixo da mínima). Pensamos que poderia ser um erro no certificado digital do cliente, mas o mesmo certificado está em uso normal no ambiente de produção. Pensamos que poderia ser um erro no ambiente de homologação da SEFAZ GO, mas usando o script Powershell em anexo (Invoke-WebRequest), conseguimos fazer funcionar o mesmo SOAPRequest que falhou no ACBrNFe_Exemplo. Alguém poderia nos dar uma luz na solução desse problema? nfe-consstatserv.ps1
  21. Semana passada foram adicionadas as units ACBr_fpdf.pas e ACBr_fpdf_ext.pas em Fontes/Terceiros/FPDF-Pascal. Elas não seguem o mesmo padrão de uso da condição de pré compilação REMOVE_CAST_WARN, das demais untis. Ambas definem essa condição logo antes de testar, e se baseiam na versão do compilador para determinar se os warnings IMPLICIT_STRING_CAST e IMPLICIT_STRING_CAST_LOSS serão desligados. O teste por CompilerVersion está errado. Está testando por CompilerVersion >= 16 (Delphi 8 for .Net), quando deveria testar por CompilerVersion >= 20 (Delphi 2009), que introduziu esses warnings. No Delphi 2007, CompilerVersion = 18.5, ainda não existem esses warnings. Versões dos compiladores. Solucionei aqui removendo o {$DEFINE REMOVE_CAST_WARN} - deveria ter sua definição centralizada, como nas demais units, correto? - e corrigindo a versão do compilador no teste. Em anexo as units alteradas, em .zip porque os .pas deram erro -200 no upload. ACBr_fpdf.zip
  22. Pesquisei aqui no forum pelos erros que relatei neste tópico, relacionados ao uso da WinCrypt. Encontrei um tópico recente onde o Italo passa algumas orientações de configuração: Testei seguindo as orientações do Italo, e funcionou! Resumindo: O erro "CryptExportKey - len" ocorre quando o certificado digital é instalado/importado no Windows, sem marcar o checkbox de "Marcar essa chave como exportável". O erro "12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor" foi resolvido configurando: ACBrNfseX1.Configuracoes.WebServices.SSLType := LT_all; Abandonaremos a CAPICOM e seguiremos com a WinCrypt + LibXml2. Obrigado a todos pela ajuda!
  23. Obrigado pela ajuda Juliomar! As DLL libeay32.dll e ssleay32.dll está na versão 1.0.2.21. Configurei as libs de acordo com as configurações padrão do ACBrNFSeX_Exemplo, quando se altera a SSLLib para libWinCrypt: ACBrNfseX1.Configuracoes.Geral.SSLLib := libWinCrypt; ACBrNfseX1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; ACBrNfseX1.Configuracoes.Geral.SSLHttpLib := httpWinHttp; ACBrNfseX1.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; Nenhum desses usa os *OpenSSL. Mesmo assim a versão do OpenSSL interfere?
  24. Funcionou Italo! Seguindo essa abordagem, achas necessário criar um param extra no provedor (ex.: Param=SoapDadosMsgCdata:), para setar somente para POA/RS? Ou faço a alteração para todos os provedores? Verifiquei no arquivo INI, e esse provedor é usado por Porto Alegre/RS e Belo Horizonte/MG.
×
×
  • 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.