Jump to content

click.png

click.png

click.png

click.png click.png click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

Data Lider

Membros
  • Posts

    83
  • Joined

  • Last visited

Contact Methods

  • Website URL
    http://www.datalider.com.br

Recent Profile Visitors

1,151 profile views

Data Lider's Achievements

Enthusiast

Enthusiast (6/14)

  • First Post
  • Collaborator Rare
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

27

Reputation

  1. Prezados, estamos tendo problemas com algumas notas de entrada de telecomunicações, não sei constatar se era uma problema com versões antigas do PVA que não validavam corretamente, ou se ninguém mesmo estava lançando notas de telecomunicações de entrada no componente da ACBR, falo isso porque olhando em guias antigos da EFD o campo TP_ASSINANTE é antigo, e a não obrigatoriedade para entrada também é. Mas fato é que o arquivo texto está indo com zero quando informado o valor TP_ASSINANTE := TACBrTpAssinante.assNenhum; no registro D500, e como zero não está previsto nem mesmo quando obrigatório, acontece um problema de validação, pelo menos nessa versão do PVA atual. Segue a correção em anexo, junto com algumas imagens para auxílio na verificação. A relação de obrigatoriedade Os valores válidos A correção Arquivo: ACBrEFDBloco_D_Class.pas Linha: 1618 ACBrEFDBloco_D_Class.pas
  2. Prezados, hoje ao realizar alguns testes em produção restrita em preparação para maio, verifiquei que o evento R-9000 deixou de funcionar. Depois de um bom tempo, verifiquei que na versão do SVN 21191 foi adicionado o novo schema do evento 2055, aumentando o tamanho da array TReinfSchemaStr, porém na implementação do arquivo pcnConversaoReinf.pas, na função StringXMLToTipoEvento está fixo o tamanho da iteração com o FOR usando essa Array. A função StringXMLToTipoEvento é usada para descobrir de qual schema de evento se trata o xml que está sendo assinado pelas LIB de Assinatura de XML, logo como o evento de exclusão é o último da array, a assinatura dele passou a não ser possível mais (Provável que afete a produção também). Segue a correção, eu já fiz o envio de um r-9000 e foi normalmente. pcnConversaoReinf.pas
  3. Não, erro meu mesmo. Obrigado! Edição do Post: Na verdade, eu não subiu a alteração para a NFC-e, ai ficou assim (igual ao primeiro), vou carregar aqui, e desculpa. (TACBrNFeDANFCEFR) ficou sem o Thread Safe. ACBrNFeDANFEFR.pas
  4. Segue os arquivos novamente, faltou adicionar a NFCe também. Olhando aqui a classe, se não quiserem implementar essa sugestão, pelo menos então se puderem deixar o objeto do tipo TACBrNFeFRClass em protected or public das classes TACBrNFeDANFEFR/TACBrNFeDANFCEFR para quem precisar dessa implementação. ACBrNFeDANFEFR.pas ACBrNFeDANFEFRDM.pas
  5. No código está condicionado a uma variável estar True, e a versão testada foi a Emb Edition. No help do componente, essa propriedade existe desde o FR4. Na versão de teste de vocês, com vários ambientes diferentes, talvez pode acontecer de algum não compilar por não existir em componentes antigos, ai seria o caso então, de condicionar também no ACBR.inc acredito.
  6. Prezados, temos um processo de geração de DANFe em massa, e precisamos acelerar ele, tivemos um percalço no caminho e problemas com as Threads porque o FastReport precisa de duas configurações para funcionarem corretamente com Threads paralelas, mesmo pedindo para silenciar os diálogos o problema acontece, e ainda tem um segundo problema que é o cache interno do FastReport, fazendo que dentro de um range muito alto de documentos algumas DANFe ficassem com o mesmo conteúdo. Felizmente basta alterar duas propriedades para resolver o problema. // Desabilita todo e qualquer tipo de mensagem frxReport.EngineOptions.SilentMode := True; // Habilita o FR a trabalhar com multiplas threads com segurança frxReport.EngineOptions.EnableThreadSafe := True; // Desabilita o cache, que no caso de múltiplas threas pode dar conflito de conteúdo entre arquivos. frxReport.EngineOptions.UseFileCache := false; Segue os arquivos atualizados. ACBrNFeDANFEFR.pas ACBrNFeDANFEFRDM.pas
  7. Obrigado pela resposta, mas no caso, como o servidor está com o timeout acima de 21, não funcionaria o cancelamento também, e nem a verificação do status, ficaria para um tratamento posterior então?
  8. Obrigado por responder, eu já havia testado sem ela, o problema continua.
  9. Contexto UF Espírito Santo Revisão ACBR 20096 Projeto ACBrNFCe Configurações SSL WinCrypt XML MSXML2 {$DEFINE USE_MINGW} Habilitado O Problema Espírito Santo, em geral, nos dias de sexta-feira (com maior incidência) tendem a ter tempo de resposta no servidor SVRS bem alto, tempos geralmente acima de 21 segundos, e nós temos acompanhando um número ligações relacionadas a timeout, o que não seria um problema se o servidor não efetivasse a nota mesmo depois do timeout gerando uma duplicidade. Mas porque não entrar em contingência? Acontece que esses picos de timeout costumam serem passageiros e de curta duração, e não exclusivos da sexta-feira, e ficar na contingência não é um cenário ideal, sendo que a internet está sempre disponível. (na imagem acima, painel monitor para o SEFAZ Virtual RS, na última sexta-feira de manhã) (se você entrar nesse painel, não vai ver o ano de 2020, para conseguir visualizar, você precisa injetar o HTML com a opção de 2020) A Solução (que não está funcionando) Existem vários tópicos aqui no fórum, explicando sobre onde, como, e porque configurar o timeout, nós fizemos isso, definimos por média 60 segundos, porque era o máximo em condições normais que o servidor registrava, o que em teoria teria resolvido o problema, inclusive gostaria de registrar o seguinte: function TACBrWinHTTPReqResp.SetConnectionTimeOut: Boolean; A função WinHttpSetTimeouts estava recebendo o timeout de 60000 normalmente, conforme inspecionado em tempo de depuração. Porém em todas os testes que fizemos, com tempos de timeouts diferentes (60s, 240s e etc..), sempre o cronometro para em 21 segundos. Os testes foram realizados conforme vídeo do DANEL testando o timeout adicionando uma porta ao final das URL existentes no arquivo INI da ACBRNFe. (Exemplo do INI) (Pontos de verificação no WinHttpSendRequest, caso alguém for realizar os testes) C:\DL\T\ac\Fontes\ACBrTCP\ACBrWinHTTPReqResp.pas O "Possível" por quê Pesquisando sobre "Timeout" + "WinHttpSendRequest" encontrei um tópico justamente a respeito disso na MSDN americana, porém quem respondeu (segundo o autor) trabalhava no time de rede do Windows, dizendo: Segundo ele (se eu entendi bem), o uso de timeouts está descontinuado, e que não existe nenhum parte exposta via a API do WinHTTP para controlar esses tempos de troca de pacotes explicitados por ele na resposta. (Link Original Aqui) OpenSSL: A Solução (que funciona em partes) Os mesmos testes feitos com a OpenSSL funcionam corretamente, o timeout é respeitado conforme informado e com precisão, porém temos o problema dos certificados A3, logo as pessoas com certificado A3 continuariam com o problema. (Pontos de verificação na unit HTTP da OpenSSL, caso alguém for realizar os testes) C:\DL\T\ac\Fontes\ACBrDFe\ACBrDFeHttpOpenSSL.pas Em quanto terminava de escrever esse tópico senti a necessidade de testar na DEMO da ACBr diretamente, sem o Mingw, por segurança, e o mesmo ocorreu, porém no nosso programa testamos com envio da nota em homologação, e na demo com o status. A Pergunta Teria como alguém realizar os mesmos testes para confirmar isso? Existe alguma solução para A3 que não a Capicom e a WinCrypt? Alguém já passou por isso, e conseguiu uma solução?
  10. Prezados, notei que o campo de Telefone no grupo Software House do registro R1000 está como obrigatório. Segue identificação no Manual No Arquivo XSD A alteração realizada no arquivo pcnReinfR1000.pas, arquivo em anexo. pcnReinfR1000.pas
  11. Daniel, após as alterações, nós inserimos a aplicação para produção em alguns clientes, para ver como reagiria, e todos os clientes com o Windows 10 e Windows Server 2012R2 funcionou muito perfeito, até mesmo assinaturas com o aplicativo rodando como serviço funcionaram bem, mesmo com A3, porém em Windows 7 a aplicação de assinatura externa falhava por diversas vezes, por esse motivo removemos o assinador externo do projeto, e todas suas chamadas.
  12. Fiz o update e os seguintes testes: Emitir duas NF-e com A1 sem aplicativo externo, Tudo OK Emitir duas NF-e com A3 Token sem aplicativo externo, Tudo OK. Emitir duas NF-e com A3 SmartCard com aplicativo externo, Tudo OK. Emitir uma MDF-e com A3 SmartCard com aplicativo externo, Tudo OK.
  13. Perfeito, e caso precise de confirmar alguma situação, estaremos com o Leitor de cartão até quarta-feira.
  14. Fiz a reversão de todos os fontes da ACBR na nossa cópia de trabalho. Fiz a seguinte alteração postada por você Então em nosso código adicionei Result := FACBR.Enviar(Lote, False); FACBR.SSL.DescarregarCertificado; Ao enviar duas notas fiscais, a segunda travou e pediu o PIN. Então ainda no nosso código adicionei mais uma linha Result := FACBR.Enviar(Lote, False); FACBR.SSL.DescarregarCertificado; // Identifica a posição do certificado na lista vPosCertPinCache := pos(FACBR.Configuracoes.Certificados.NumeroSerie, ACBrDFeWinCrypt.CertificadosA3ComPin); // Se foi identificado, então remove apenas ele. if vPosCertPinCache > 0 then Delete(CertificadosA3ComPin, vPosCertPinCache, Length(FACBR.Configuracoes.Certificados.NumeroSerie + ',')); Enviei 3 notas e nenhuma delas deu erro ou pediu o PIN, tanto no Token quando no SmartCard. Se quiser, posso fazer a alteração em todos os valida CNPJ de todas as classes que herdam a DFe e modificar de acordo com seu código e postar aqui para subir.
  15. Veja a seguinte situação: Primeiro, descarregando o certificado após a verificação do CNPJ procedure NotaFiscal.Assinar; var XMLStr: String; XMLUTF8: AnsiString; Leitor: TLeitor; begin with TACBrNFe(TNotasFiscais(Collection).ACBrNFe) do begin SSL.ValidarCNPJCertificado( NFe.Emit.CNPJCPF ); if Assigned(SSL.AntesDeAssinar) then SSL.DescarregarCertificado; end; Quando descarrega o contexto, remove a trava do pin procedure TDFeWinCrypt.DescarregarCertificado; var PosA3Pin: integer; begin // Limpando objetos da MS CryptoAPI // if Assigned(FpCertContext) then begin if Assigned(FpDadosCertificado) then begin PosA3Pin := pos(FpDadosCertificado.NumeroSerie, CertificadosA3ComPin); if PosA3Pin > 0 then Delete(CertificadosA3ComPin, PosA3Pin, Length(FpDadosCertificado.NumeroSerie + ',')); end; CertFreeCertificateContext(FpCertContext); end; Desta forma, duas nota seguidas foram enviadas sem pedir o PIN ou apresentar o erro, é claro que é apenas um teste, e de forma nenhum trata todas as possibilidades. Nesse caso foi testado com um Leitor Perto (SafeSign) e com um SafeNet Token 1500. Eu vi também no MSDN que é possível liberar o cache do pin enviando nulo para NCryptSetProperty ou mesmo CryptSetProvParam.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.