Data Lider

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

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) 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. o evento foi transferido para o BeforePrint da banda PageFooter1. teste.xml

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 abaixo 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: DANFSeNovo.fr3

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 ACBrNFSeXServicos.ini

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. ACBrNFeDANFeESCPOS.pas

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

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

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

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

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. ACBrNFeDANFEFR.pas ACBrNFeDANFEFRDM.pas

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?

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.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?

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