Pesquisar na Comunidade

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

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

Contextualizando Prezados, devido nossa aplicação ser em 3 camadas, a parte de assinatura do XML fica em uma aplicação externa em outra linguagem de programação, e no que diz respeito a parte de ENVIO basta mencionar o excelente trabalho que o projeto fez com a WinCrypt. obs: se você não sabe o porque de fazermos assim, segue o tópico EXCELENTE do Daniel O Problema Essa semana obtivemos um certificado A3 da Perto (SmartCard) e ele está pedindo PIN no servidor, e no DEBUG descobri que não era na nossa rotina de assinatura mas sim no momento do envio pela ACBr. A Causa Na unit "ACBrNFeNotasFiscais.pas", na linha 252, onde temos: TACBrNFe(TNotasFiscais(Collection).ACBrNFe).SSL.ValidarCNPJCertificado( NFe.Emit.CNPJCPF ); 1º Ele acaba inicializando todo contexto e enviando o PIN para o SmartCard (ou Token) previamente, antes da assinatura e antes do envio. 2º Quando o evento "OnAntesDeAssinar" é disparado nosso código externo realiza a assinatura do XML nessa biblioteca externa. 3º (Não tenho certeza) É provável que ao adquirir o contexto do certificado A3 nessa aplicação nossa, e enviar o PIN tem removido o contexto da ACBR ou algo semelhante, isso já vai um pouco além do que conheço do assunto. 4º Quando o código volta para a ACBR realizar o Envio, a janela de PIN aparece. 5º Quando debugando eu faço um Jump para a próxima linha pulando a linha 252 conforme destacada acima, tudo funciona normalmente, porque não houve um contexto anteriormente adquirido acima, então no momento do envio o código para obter a chave privada funciona como se fosse executado a primeira vez. Obs: CertFreeCertificateContext também é chamado em nossa aplicação depois da assinatura do XML ser concluída, e o Store dos certificados é fechada. Possíveis Soluções Aqui que venho pedir ajuda ao pessoal responsável pelo projeto para não fazer alterações desnecessária ou que não serão aceitas. De imediato pensei em para as pessoas que assinam os XMLs em aplicações externas fica a responsabilidade da validação do CNPJ e o certificado, assim adicionando uma verificação se o evento OnAntesDeAssinar está "Assigned" antes linha 252 e resolvendo esse problema. Ou então a rotina que verifica se o CNPJ é o mesmo do certificado não realizar o envio do PIN quando o tipo for A3 por exemplo // Talvez adicionar um parametro padrão como TDFeWinCrypt.CarregarCertificado; Para TDFeWinCrypt.CarregarCertificado(const EnviarPinSeExistir: Boolean = True); E aqui seguindo a lógica de enviar o parâmetro falso para o CNPJ, até chegar na unit que verifica se os dois CNPJ são os mesmos. function TDFeSSLCryptClass.GetCertCNPJ: String; begin CarregarCertificadoSeVazio(False); Result := FpDadosCertificado.CNPJ; end; Desculpe se ficou muito extenso.

Prezados, gostaria de registrar aqui, que passamos na homologação do TEF da NTK usando o componente da ACBr + Firemonkey. Lembrando que se for fazer os testes do TEF em FMX existe um item para ser levantado ainda que está esperando análise, você pode baixar o arquivo no post abaixo em quanto isso.

Prezados, implementado o fechamento do dia, me deparei com informações importantes aqui do fórum e bem espalhadas sobre a redução Z. Alguns modelos pedem totalizadores depois da redução z (Alguns tópicos confirmam isso, conversei com o regys ele também afirmou). O ideal é utilizar tanto o DadosReducaoZ como UltimoDadosReducaoZ como em alguns tópicos. Na chamada da redução Z é interessante uma configuração de timeout para evitar problemas (blog do regys). Em algum tópico o Daniel posta um código para mesclar arquivos INI para permitir utilizar de forma mais simplificada as funções DadosReducaoZ e UltimoDadosReducaoZ. Diante dessas informações nós iniciamos uma solução para as questões acima, e tentamos inserir ela dentro da classe ACBrECFClass. Vou tentar explicar de forma simples. type TACBrECFDadosRZ = class public procedure CarregaINIReducaoZ(const DadosReducaoINI: TMemIniFile); procedure CarregaMesclandoINIReducoesZ(const Origem, Destino: string); end; TACBrECFClass public function ReducaoZ_Otimizada( DataHora : TDateTime = 0 ): TACBrECFDadosRZ; end; O procedimento CarregaINIReducaoZ foi implementada para fazer a leitura do arquivo INI gerado pela própria classe TACBrECFDadosRZ e se auto alimentar as informações, recuperando alíquotas e totalizadores, auto alimentando a classe, no meu ponto de vista a implementação ficou bem segura e respeitando os critérios do procedimento responsável pela geração MontaDadosReducaoZ. O procedimento CarregaMesclandoINIReducoesZ foi criado do zero mas usando a ideia da função já postada aqui no fórum, ela sempre tenta permanecer o valor do destino caso o valor da redução de origem seja nula, zero ou etc... A função ReducaoZ_Otimizada, realiza o procedimento de aumento de TimeOut postado pelo Regys além de armazenar o INI da função DadosReducaoZ, armazenar o INI da função DadosUltimaReducaoZ, mesclar os dois e carregar para o retorno da função a redução Z completo e acessível por pela classe TACBrECFDadosTZ, combinando as implementações anterior. Vantagens Utilizando a leitura pela classe e não pelo INI resultante do processo de mesclagem, as futuras alterações realizadas na classe são sentidas no momento da compilação (quando alterado no svn e atualizado), diferente da leitura pelo INI dentro do seus sistema, que somente depois que ser executado que uma alteração de tipo ou objeto seria identificada. Simplifica o processo da redução Z para quem não conhece os problemas de compatibilidade das impressoras. Evita o problema com TimeOut nas reduções Z. Função ReducaoZ Otimizada: function TACBrECFClass.ReducaoZ_Otimizada(DataHora: TDateTime): TACBrECFDadosRZ; var OldTimeOut: integer; ReducaoAntes, ReducaoDepois: string; begin ReducaoAntes := DadosReducaoZ; OldTimeOut := TimeOut; try TimeOut := 600; // 10 minutos ReducaoZ( DataHora ); finally TimeOut := OldTimeOut; end; ReducaoDepois := DadosUltimaReducaoZ; Result := TACBrECFDadosRZ.Create; Result.CarregaMesclandoINIReducoesZ(ReducaoAntes, ReducaoDepois); end; Como Utilizar: procedure TForm3.Button1Click(Sender: TObject); var Reducao: TACBrECFDadosRZ; begin Reducao := ACBrECF1.ECF.ReducaoZ_Otimizada(Now); try //Leitura das variáveis desejadas aqui. finally Reducao.Free; end; end; Estou anexando as units, e um demo que sem realizar a redução z, alimenta 3 memos e compara o arquivo ini Antes da Redução, Depois da Redução e o Arquivo Final Mesclado. (Demo em firemonkey²) ACBrSerial.zip DemoUtilizaçãoReducaoMesclagem.zip