Painel de líderes

Bom dia pessoal. Como todos sabem, na maioria das vezes em que o windows se atualiza ele marca aquelas opções de certificados revogados em "Opções da internet > Avançado" e, pelo menos comigo, gera uma grande quantidade de suporte à clientes. O correto é ficar assim: ( ) Usar SSL 2.0 (x) Usar SSL 3.0 (x) Usar TSL 1.0 ( ) Usar TSL 1.1 ( ) Usar TSL 1.2 ( ) Verificar revogação de certificados servidor* (x) verificar se ha assinaturas em programas baixados ( ) Verificar se há revogação de certificados do editor Então no final do ano passado até cheguei a comentar em um tópico se teria como modificar esses dados diretamente pelo delphi, pra facilitar nossa vida, mas não tinha ninguém com essa informação. Pois bem, essa semana tive um tempinho e comecei a mexer com isso e creio que encontrei uma solução, segue abaixo programação para alterar o registro do windows com as opções corretas. Já testado em alguns clientes e até o momento funcionando perfeitamente. (Testado em windows XP, 7, 2003 server) uses Registry; procedure TFPrincipal.FormCreate(Sender: TObject); var Registro: TRegistry; begin //acertando opções da internet (revogados / SSL / TSL) //verificar revogação de certificados do servidor Registro := TRegistry.Create(KEY_WRITE); Registro.RootKey := HKEY_CURRENT_USER; if registro.OpenKey('Software\Microsoft\Windows\CurrentVersion\Internet Settings', true) then begin Registro.WriteInteger('CertificateRevocation', 0); end; registro.CloseKey; //verificar se há certificados revogados do fornecedor if registro.OpenKey('Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing', true) then begin Registro.WriteInteger('State', 146944); end; registro.CloseKey; //Usar SSL 3.0 / Usar TSL 1.0 if registro.OpenKey('Software\Microsoft\Windows\CurrentVersion\Internet Settings', true) then begin Registro.WriteInteger('SecureProtocols', 160); end; registro.CloseKey; registro.Free; end; Espero ajudar o pessoal do ACBr com essa contribuição. Um abraço a todos.

Saquei. Então, tem que falar com o PROVEDOR, no caso o SimpliSS. Fora isso, o XML está correto, porque é o XML que me é retornado. Vou falar com o SimplISS amanhã. Do resto acredito que esteja tudo certo. Obrigado, Italo.

Mensagem recebida diretamente do SEFAZ - SC em 02/06/2016. "Santa Catarina não irá adotar a NFC-e, modelo 65." Realmente lamentável e revoltante, pois todos os estados possuem nfc-e, menos SC. Isto deveria ser uma obrigação federal, que todos as UF tivessem que aderir, assim como a NFE.

Descobri qual era o problema. Na versão anterior eu tinha alterado o CNPJ do contribuinte para um CNPJ real e não utilizava o "11.111.111/1111-11" que o manual do emulador pede para usar. Nas versões anteriores eu conseguia emitir e cancelar sem problemas. Já nessa nova a emissão continuou funcionado porém dava o problema no cancelamento, acredito que nas ultimas alterações do emulador ele só reconheça como válidas as chaves que contenham o CNPJ "11.111.111/1111-11" na hora do cancelamento. Estranho que a emissão é efetuada normalmente. Mas de qualquer forma era apenas as configurações do emulador mesmo. Obrigado pela ajuda carlosmarian.

consegui reproduzir o problema, em um OpenSuse64... estou analisando o caso...

Não creio que a modificação seja necessária... dynlibs.inc TLibHandle = System.THandle; sysutilh.inc THandle = System.THandle;

OK, de acordo... apliquei modificações em ACBr.inc, para facilitar o desligamento dos Warnings

Boa tarde, Estou com um cliente que estamos com um problema ao ler o NossoNumero no retorno 240 quando o CodigoCedente são 6 dígitos. Foi verificado no fonte que o mesmo pega o código do cedente na unit "ACBrBancoBrasil.pas": rConvenioCedente:= Trim(Copy(ARetorno[0], 33, 9)); Porém conforme o layout do banco são 9 dígitos preenchidos com zeros a esquerda caso o mesmo não possua todos registros, então por exemplo dessa forma o o meu cliente possui 6 e o resto é preenchido com zero e mais abaixo é pego o NossoNumero com a seguinte linha: if Length(ACBrBoleto.Cedente.Convenio) = 6 then NossoNumero := copy(Linha, 44, 10) else NossoNumero := copy(Linha, 45, 10); Mas como ele preenche com os zeros, então o mesmo sempre está vindo 9 caracteres, alterei a seguinte linha, para: rConvenioCedente:= IntToStr(StrToInt((Copy(ARetorno[0], 33, 9)))); Assim na checagem se o mesmo possui 6 caracteres ele está retornando o NossoNumero correto.. OBS: Isso só ocorre se o Covenio do Cedente for com 6 caracteres. Isso é um erro ou estou fazendo de forma errada? Ah também alterei o tamanho da conta para 5, pois ao enviar para o banco no boleto estava preenchendo a conta com zeros a esquerda e eles não validaram dessa forma, eu verifiquei que ele pega através do tamanho da conta que vem padrão 12 fpTamanhoConta := 12; Alterei para: fpTamanhoConta := 5; e no boleto saiu a conta certa sem os zeros a esquerda. Segue a minha classe alterada em anexo... ACBrBancoBrasil.pas

Desculpa Juliana, faz um tempinho e não estava lembrando ao que se referia o post, o que eu falei não tem nada haver realmente. O ocorrido era no momento da impressão, que com a função citada no post está correto. Obrigado!

O problema seria para processar o retorno do CNAB mesmo, na impressão está ok, com essa função que você citou retira os zeros a esquerda..

Bom dia. No caso o problema seria o boleto impresso? Se sim verifique se seus fontes estão atualizados, observe que a função MontarCodigoCedente() já faz um tratamento para evitar os zeros a esquerda. Result := ACBrTitulo.ACBrBoleto.Cedente.Agencia+'-'+ ACBrTitulo.ACBrBoleto.Cedente.AgenciaDigito+'/'+ IntToStr(StrToIntDef(ACBrTitulo.ACBrBoleto.Cedente.Conta,0)) +'-'+ ACBrTitulo.ACBrBoleto.Cedente.ContaDigito; Att,

O banco informou que a conta não possuía zeros a esquerda na conta... Diferente do banco da caixa entre outros que permitem zeros a esquerda...

@Daniel Simoes Na unti ACBrEAD.pas você não removeu 1078, nela temos esse valor: Verifiquei e ele só é utilizado dentro do loop abaixo: E se entrar no loop ela recebe um valor de uma forma ou de outra. Por esse motivo temos o aviso abaixo: Você pode assim que possível aplicar essa correção pra gente? Com isso encerro por enquanto a minha tarefa pois não recebo mais nenhum aviso quando utilizo os fontes do ACBr. Para conseguir isso adicionei nos meus fontes no ACBr.inc e no RLReport.inc e com isso estou livre desses avisos.

como sempre preciso nas informações, Problema resolvido, Amigo Italo.

Olá amigos, Segue mais algumas informações referente ao uso do ACBr em Linux 64 bits. Fiz uma comparação debugando linha a linha com 2 maquinas lado a lado uma de 32 e outra de 64 bits Segue as imagens anexas. Percebi que na maquina 32bits no debug tenho a seguinte informação SignNode = xmlnodeptr($08D57050) = record XMLNODE { _PRIVATE = $0 .... Já na maquina de 64bits no debug tenho a seguinte informação SignNode = <XMLNODE> { _PRIVATE = $0, .... Após algumas pesquisas na internet parece que o libxml2 não encontra o XMLNODE especificado, apesar de não gerar a exceção, ele não traz o nó correto para assinatura. Ainda continuo dando "tiros no escuro", se alguém tiver alguma ideia de como posso prosseguir daqui ... Lembrando que no sistema de 32bits tudo funciona perfeitamente. Abraços

Enviei uma possível correção para o SVN....

Bom dia. Alteração disponível no svn. Att,

Por acaso você ou seu cliente não utilizou algum programa da própria sweda ou a dll para gerar algum arquivo fiscal, fita detalhe, etc? Pergunto pq já aconteceu comigo de fazer isso, e o programa da sweda alterar a velocidade da impressora para gerar a informação. Tente conectar utilizando outras velocidades que deve funcionar, ou utilize o lacrador da sweda para verificar a velocidade atual, e ajustar para velocidade que você já utilizava.

Graça, eu tenho o RXLib que roda até o XE3. Caso haja interesse lhe envio por pvt.