Data Lider
-
Total de ítens
88 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Data Lider
-
-
1 hora atrás, Victor H. Gonzales - Panda disse:
tem um xml para simular o caso aqui?
Segue o xml para teste do problema, devido o texto ser repetido tente selecionar com o mouse para ver que ele está por trás da imagem. (Alguns dados troque por zeros e xxxx)
Citarjá existe o tratamento do width 16 para isso, no código enviado foi pego o tamanho do memo - tamanho do image, que chegaria nos 16 da mesma forma
Então, a respeito disso, como mencionado no tópico, o evento foi transferido para o BeforePrint da banda PageFooter1, logo essa abordagem fixa não funcionou mais, não sei explicar o motivo, mas basta trocar o local do evento e deixar o mesmo código que você vai confirmar o problema.
Citarporem o evento para executar a redução foi removido
o evento foi transferido para o BeforePrint da banda PageFooter1.
-
Prezados, tivemos algumas ocorrências de clientes ligando devido algumas partes cortadas da observação na DANFSe do arquivo "DANFSeNovo.fr3".
Conforme pode ser observado abaixoCitar
O Problema
Nós identificamos que esse problema já foi tratado em algum momento dentro do próprio arquivo "DANFSeNovo.fr3", porém o tratamento pode funcionar diferente a depender do versão do FastReport (assim nós imaginamos).
No AfterPrint da do componente imgQrCode, foi adicionado um código que fixa o width do campo Memo34 para 16. O problema de fazer dessa forma, é que isso não garante que a observação já não tenha sido "processada" antes pelo relatório, fazendo que o código do AfterPrint do imgQrCode não altere a observação, além de dificultar o teste porque hora o Fast pode processar o imgQrCode depois do Memo34, gerando aquele problema que uma hora da certo, e outra hora da errado.Como resolvemos
O evento foi removido do AfterPrint de imgQrCode, e adicionado no BeforePrint da banda PageFooter1, e o código ajustado para funcionar no novo local.
// Código anterior dentro do relatório if imgQrCode.Visible then memo34.Width := 16;Depois:
// Código depois da alteração if imgQrCode.Visible then memo34.Width := memo34.Width - imgQrCode.Width;Resultado:
Citar
-
1
-
-
Prezados, segue dados do provedor dos municípios de Sooretama e João Neiva no Espírito Santo, já suportados pela ACBR.
Sooretama:
[3205010] Nome=Sooretama UF=ES Provedor=EL Versao=2.04 ProRecepcionar=https://es-sooretama-pm-nfs-backend.cloud.el.com.br/producao20/NfseWSService HomRecepcionar= ; ProLinkURL=https://es-sooretama-pm-nfs.cloud.el.com.br/paginas/sistema/login.jsf#/autenticacao?cpfCnpj=%Cnpj%&chave=%CodVerif% HomLinkURL=
João Neiva:
[3203130] Nome=Joao Neiva UF=ES Provedor=EL ProRecepcionar=https://es-joaoneiva-pm-nfs.cloud.el.com.br/RpsServiceService HomRecepcionar= ; ProLinkURL=https://es-joaoneiva-pm-nfs.cloud.el.com.br/paginas/sistema/autenticacaoNota.jsf?cpfCnpj=%Cnpj%&chave=%CodVerif% HomLinkURL=https://es-joaoneiva-pm-nfs.cloud.el.com.br/paginas/sistema/autenticacaoNota.jsf?cpfCnpj=%Cnpj%&chave=%CodVerif%
Todos dois testados em produção.
Arquivo na revisão 30965
-
Prezados, existem outros tópicos de pessoas que questionaram, pediram ou sugeriram a adição da possibilidade de impressão de NFE com o componente ACBrNFeDANFeESCPOS.
No último tópico a respeito disso foi sugerido que fosse alterado ACBrNFeDANFeESCPOS para ACBrNFCeDANFeESCPOS, e que o ACBrNFeDANFeESCPOS fica-se apenas para NF-e.
- Eu alterei o código ACBrNFeDANFeESCPOS e adicionei apenas duas propriedades (que podem ser renomeadas talvez para algo mais adequado) para determinar a adoção da "NT2020.004 - DANFE_SIMPLIFICADO v1.00" que prevê a DANFE em modelo reduzido.
- Como a NT não determinar um layout, mas sim apenas campos obrigatórios, eu preservei o máximo do layout atual do arquivo atual, bem como do código.
- Algumas impressoras ESCPOS não consegue imprimir códigos de barras c128 com 44 dígitos, o que teoricamente (questão de interpretação talvez da NT?) inviabiliza o uso do modelo, mas mesmo assim adicionei uma propriedade para desativer a impressão do código de barras c128 da chave de acesso.
-
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
-
A relação de obrigatoriedade
-
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.
-
1
-
-
17 horas atrás, Juliomar Marchetti disse:
algum motivo pra isso?
Corrigi e subi.
caso ocorra problemas e houver relatos vou reverter
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.
-
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.
-
1
-
-
19 horas atrás, Juliomar Marchetti disse:
Boa tarde
pode ser que habilitando pare de funcionar para algumas pessoas pois senão me engano isso só serve no enterprise.
seria necessário testes para validar isso
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.
-
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.
-
1
-
-
2 minutos atrás, Daniel Simoes disse:
Existem várias situações possíveis de Erro de TimeOut... e realmente o Sistema Operacional, pode interferir...
Verifique ainda a propriedade TimeOutPorThread, na qual o próprio ACBR irá abandonar a conexão, quando o TimeOut ocorrer...
Mas pelo que você descreveu.. você não está tratando corretamente as situações de TimeOut... e acionamento de Off-line
O fato do TimeOut ocorrer, não significa que o XML não foi entregue ao servidor... a lentidão poderia esta no caminho da resposta do XML, por exemplo...
Sempre que houver erro de TimeOut... você PRECISA consultar no SEFAZ, o Status do documento onde ocorreu o TimeOut...
Se ele existir no SEFAZ, você deve cancelar, pois essa Nota já foi tributada, pela nota emitida em contingência...Aqui há uma coletânea de tópicos e vídeos, sobre esse assunto:
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?
-
5 minutos atrás, Juliomar Marchetti disse:
Não utilize mais {$DEFINE USE_MINGW}
Obrigado por responder, eu já havia testado sem ela, o problema continua.
-
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.pasO "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.pasEm 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?
-
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.
-
19 horas atrás, Daniel Simoes disse:
Após analisar o tópico abaixo, notei que a modificação que efetuamos aqui.. ocasionou efeitos colaterais...
Pensando nisso, aplique modificações na Unit ACBrDFeWinCrypt.pas, a fim de tentar resolver o problema... porém gostaria que você verificasse se essas modificações funcionarão para o caso relatado aqui nesse post.
Por favor teste seus fontes, com a Unit em anexo...
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.
-
2 horas atrás, Daniel Simoes disse:
ok.. já no SVN...
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.
-
1
-
1 hora atrás, Daniel Simoes disse:
Hum.. então o que faltou, foi que ao Descarregar o Certificado, devemos remover ele da Lista de Pins salvos... correto ?
Perfeito, e caso precise de confirmar alguma situação, estaremos com o Leitor de cartão até quarta-feira.
-
1
-
-
1 hora atrás, Daniel Simoes disse:
No objeto DFeSSL há métodos para carregar e descarregar o certificado...
Deve funcionar, se aplicarmos a modificação sugerida ( não validar o CNPJ, para quem programou o evento ) e você descarregar o certificado de DFeSSL, após o envio...
- Fiz a reversão de todos os fontes da ACBR na nossa cópia de trabalho.
-
Fiz a seguinte alteração postada por você
Em 18/08/2017 at 13:43, Daniel Simoes disse:
A opção 1, parece fazer mais sentido... (verificar se há um evento externo para assinar)
procedure NotaFiscal.Assinar; var XMLStr: String; XMLUTF8: AnsiString; Leitor: TLeitor; begin with TACBrNFe(TNotasFiscais(Collection).ACBrNFe) do begin if not Assigned(SSL.AntesDeAssinar) then SSL.ValidarCNPJCertificado( NFe.Emit.CNPJCPF ); end;mas isso não apenas adiaria o problema ? Pois ambas aplicações precisam usar o certificado.. e acho que depois do ACBr atribuir o PIN, para efetuar o envio... provavelmente sua aplicação tenha problemas para usar o certificado, na próxima assinatura...
-
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.
-
Veja a seguinte situação:
Primeiro, descarregando o certificado após a verificação do CNPJprocedure 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.
-
Em 18/08/2017 at 13:43, Daniel Simoes disse:
A opção 1, parece fazer mais sentido... (verificar se há um evento externo para assinar)
procedure NotaFiscal.Assinar; var XMLStr: String; XMLUTF8: AnsiString; Leitor: TLeitor; begin with TACBrNFe(TNotasFiscais(Collection).ACBrNFe) do begin if not Assigned(SSL.AntesDeAssinar) then SSL.ValidarCNPJCertificado( NFe.Emit.CNPJCPF ); end;mas isso não apenas adiaria o problema ? Pois ambas aplicações precisam usar o certificado.. e acho que depois do ACBr atribuir o PIN, para efetuar o envio... provavelmente sua aplicação tenha problemas para usar o certificado, na próxima assinatura...
Olá Daniel, obrigado pela atenção, e realmente, com duas notas seguidas o problema acaba acontecendo, você tem alguma sugestão?
Talvez adicionar uma propriedade TDFeSSL e em TDFeSSLCryptClass para definir se mantem o certificado carregado, ou não, então sempre que pedir o carregamento e após fazer o uso liberar.
Ou então tentar manter o mesmo contexto em duas aplicações diferentes usando o mesmo handle (não sei se é possível).
-
Segue sugestão de alteração, dessa forma mesmo usando assinatura de XML por biblioteca externa funciona sem problemas.
Revisão: 13736
-
Olha, conforme dentro deste procedimento que você mencionou, o parâmetro é definido como False, porque os certificados do tipo CNG - "Cryptography API: Next Generation". retornam erro com essa requisição.
-
De mais detalhes sobre o problema
- O certificado não encontrado está no repositório de certificados do Windows?
- Se estiver lá, comparou o Serial dele com o serial que a sua aplicação está enviando para a ACBr?
- Sua aplicação roda como serviço?
- O certificado está instalado no repositório "Pessoal"?
- Pelo ACBrNFeDemo o processo de envio está funcionando?
-
Teoricamente se o processo está sendo executado corretamente pela ACBr, e o congelamento que você diz é devido ao tempo de execução, então cabe a você tratar isso na sua aplicação, no mínimo usar Thread para processos mais demorados.
DANFSe - Observação por trás da imagem do QRCode
em ACBrNFSe
Postado · Editado por Data Lider
ortografia
A EL está na maioria das cidades atendendo o padrão ABRASF agora, porém algumas cidades que não atualizam para a versão nova do provedor E&L ainda acabam usando o padrão deles, vai depender da cidade. A questão da observação você está correto, não estava saindo com o XML que mandei, acontece que a EL não permite usar o campo <OutrasInformacoes> durante a transmissão do XML, esse campo ficou exclusivamente para a prefeitura preencher com informações internas deles, ai o XML que te mandei está com o campo <InformacoesComplementares>, antes da impressão quando o provedor é E&L nosso sistema copia as informações para sair também na parte de baixo alimentando o campo OutrasInformacoes do DANFE.
No XML que mandei agora eu troquei o campo InformacoesComplementares por OutrasInformacoes assim irá funcionar nos seus testes. E também fiz um teste usando a demo da AcbrNFSeX + Fast e consegui testar com sucesso fazendo assim. Eu anexei o XML alterado.
teste.xml