Valdir Dill

Boa tarde, Tive várias ocorrência desse erro em vários clientes nos últimos dias. Não consegui identificar a causa, mas é muito provável que seja alguma instabilidade ou local ou no WS, pois alguns minutos depois, com uma nova tentativa, a nota simplesmente era transmitida normalmente. Abraços!

Bom dia Italo, Obrigado pela informação. Sua resposta é o que eu imaginava, ou seja, que as mudanças da Wincrypt seriam para todos os componentes de documentos eletrônicos. O que ocorreu é que eu tenho uma rotina que configura exatamente da mesma forma (em relação ao SSL), tanto o ACBRNFe e ACBRNFSe. Mas no ACBRNFSe deu um erro de 12002 (falha no envio da requisição). Esse erro ocorreu em um cliente e ainda não consegui reproduzi-lo aqui em laboratório para poder debugar. Vou tentar pesquisar mais. Mas beleza, está esclarecida a dúvida inicial. Obrigado!

Boa tarde, Talvez eu não tenha me expressado de forma correta, mas a dúvida maior não é o demo e sim se podemos configurar o TACBRNSFe com as mesmas inovações (WinCrypt) do TACBRNFe. Logicamente que me refiro ao parte do SSL -> TAcbrNFSe.Configuracoes.Geral.SSLLib := WinCrypt. Obrigado!

Bom dia, Pelo que vejo no demo da NFSe, a nova opção para substituição da Capicom pela WinCrypt ainda não está implementada, correto? Mas vai ser implementada, certo? Alguma previsão? Obrigado!

Bom dia, Tive esse erro na rotina ACBrNFe1.SSL.NumeroSerie := ACBrNFe1.SSL.SelecionarCertificado, mas apenas quando se selecionava um certificado A1 na lista de certificados. Mudei as rotinas do sistema para não deixar o operador cometer esse erro. Abraços

Bom dia, Certificado A3 da Caixa Econômica Federal. Usa o gerenciador Charismatics. http://www.caixa.gov.br/empresa/identidade-digital/Paginas/default.aspx Obrigado!

Debugado e não ocorreu nenhum erro. Chegou até na linha 566 com pfCallerFreeProv = true. Fiz outro teste informando a senha errada propositadamente. Aí deu o erro "O cartão não pode ser acessado porque o PIN errado foi apresentado" nessa procedure. Ou seja, o componente está recebendo a senha de forma correta, está testando ela e está passando, tudo certo. Já estamos ficando sem opções, hehe! Acho que vou tentar remover o Charismatics (gerenciador do certificado) e reinstalá-lo. Vi num post mais antigo um colega que estava com problema parecido e reinstalou o gerenciador e resolveu. O dele era Certisign, mas.... Obrigado!

Conforme relatei, eu já fiz esse teste de colocar a senha, inclusive no demo, sem resultados positivos. Mas agora me levantou uma dúvida. É possível eu setar a senha em um A3 e, com isso, ele não pedir mais a senha, ou seja, dispensaria a janelinha de login, é isso? Nunca consegui fazer isso. Eu atribuo a senha (ACBrNFe1.SSL.Senha := 'senha'), mas a janelinha do login é solicitada igual. Isso no caso da Capicom, pois no caso da libWinCrypt está com esse problema. Só me confirma isso então, se ACBrNFe1.SSL.Senha tiver valor, a janelinha de login do certificado NÃO deve aparecer? Se for isso, então deve ser algo no meu certificado ou no gerenciador dele. Obrigado

Concordo. Nitidamente é essa a impressão que dá. É como se a tela estivesse aberta aguardando se digitar a senha. Mas tive esse problemas da tela de senha ficar "por trás" no passado e posso garantir que a tela do certificado não está ativa, nem mesmo em segundo plano. Já fiz todas as análises possíveis no intuito de verificar se a telinha está em segundo plano, mas não está. Minha opinião é que tem alguma coisa impedindo que a tela seja apresentada Se configurar para Capicom, o problema não acontece.Além disso, com o F8 depois do break point o processo flui normal, mas com F9, não. Muito sinistro. Algum outro colega que acompanha este post já testou a nova libWinCrypt com A3? Talvez seja meu certificado ou máquina conflitando com alguma rotina nova do Acbr, sei lá. Obrigado!

Exato Daniel, congela nesse ponto. Olha outra coisa coisa que descobri agora: Se eu colocar um break point nessa linha 277 ( if not WinHttpSendRequest( pRequest,...) da ACBrWinHTTPReqResp.pas. Aí a compilação para ali. Então pressiono F9 e nada, fica congelado. Já fiz um teste aguardando 1 minuto. Se deixar sem break point, também não vai. Porém, se nesse break point eu pressionar F8 e não o F9, ele processa normal, ou seja, abre a telinha de login do certificado certinho. Será que não é alguma coisa no sistema do certificado ou da máquina? O estranho é que configurando para Capicom ele funciona, como sempre funcionou. Obrigado!

Bom fia, ACBrNFe1.SSL.Senha := 'senha', certo? Infelizmente não é o caso. Eu realmente não tinha colocado a senha. Mas fiz novos testes agora informando a senha do certificado e ficou na mesma. Testei tanto no meu sistema, como no demo. Obrigado!

Bom dia Daniel, Obrigado pelo retorno: Seguinte: Sobre o "código demais", ainda estamos aprendendo o que devemos e o que não devemos setar, hehe! Eu setei as 4 propriedades porque no demo também está setando. Então, se entendi corretamente a sua orientação, é preciso apenas atribuir um valor para Configuracoes.Geral.SSLLib. As outras 3 o componente assume automaticamente em consequência disso, está correto? Mudei a propriedade "Configuracoes.Geral.SSLHttpLib := httpWinINet" conforme você sugeriu e aí deu tudo certo. A telinha do login apareceu em 2 segundos. Obs.: 1) Na mudança acima, mantive Configuracoes.Geral.SSLLib := libWinCrypt; 2) Ao efetuar a mudança, o comportamento é o mesmo tanto no meu sistema, como no demo ACBR, ou seja, se deixo SSLHttpLib := httpWinINet, a tela de login do certificado aparece e o processo flui normalmente, mas se mudar para SSLHttpLib := httpWinHttp, a tela de login não aparece e a compilação vai só até essa linha da unit que informei no post inicial e trava. Não tenho como prosseguir com o debug a partir dali. Configuracoes.WebServices.TimeOut = 5000 Obrigado!

Boa tarde, A configuração ficaria assim, certo? acbreNFe1.Configuracoes.Geral.SSLLib := libWinCrypt; acbreNFe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; acbreNFe1.Configuracoes.Geral.SSLHttpLib := httpWinHttp; acbreNFe1.Configuracoes.Geral.SSLXmlSignLib := xsMsXml; Fiz essa mudança e a demora na rotina AcbreNFe1.SSL.CarregarCertificado continua(5 a 6 segundos). Mas agora há um outro problema. A execução simplesmente trava em um certo ponto. Consegui debugar até a linha 277 da ACBrWinHTTPReqResp.pas, ou seja, na rotina "if not WinHttpSendRequest( pRequest, LPCWSTR(wHeader), Length(wHeader), WINHTTP_NO_REQUEST_DATA, 0, Length(Self.Data), 0) then.... Depois disso não anda mais e nenhum erro acontece, nada.. Alguma dica? Obrigado! Desculpem a emenda, mas deixei de passar 3 informações que acho são importantes: 1 - Fiz todos os testes também no demo ACBR e o mesmo problema do travamento também ocorre; 2 - Não chega nem a ser mostrada a telinha de login do certificado; 3 - Se eu mudar para libCapicom ou libCapicomDelphiSoap, tanto no meu sistema, domo no demo ACBR aí funciona beleza. Obrigado!

Bom dia, Depois da última atualização dos fontes, a função AcbreNFe1.SSL.CarregarCertificado ficou bem mais lenta. Isso é normal ou será que estou deixando de configurar algo? Obs.: isso acontece apenas na primeira vez que essa rotina é executada. Se executar pela segunda vez, não há nenhuma demora. Configuração utilizada: - Certificado A3; - AcbreNFe1.Configuracoes.Geral.SSLLib := libCapicomDelphiSoap; - AcbreNFe1.Configuracoes.Geral.SSLCryptLib := cryCapicom; - AcbreNFe1.Configuracoes.Geral.SSLHttpLib := httpIndy; - AcbreNFe1r.Configuracoes.Geral.SSLXmlSignLib := xsMsXmlCapicom; Obrigado!

Bom dia, Estou analisando as mudanças que estão sendo feitas para o "bye bye Capicom", rs. Em primeiro lugar quero registrar minha satisfação em saber dessas mudanças. A Capicom realmente dá muitos problemas de configuração nos usuários, o que gera suporte e mais suporte. Uma situação que me surgiu e gostaria de uma ajuda seria como configurar as opções de SSLLib, SSLCryptLib, SSLHttpLib e SSLXmlSignLib. Aproveito para colocar minha dúvida e já fazer uma sugestão. Logicamente que precisamos estudar mais os fontes e o demo, mas acho que se vocês colocarem as configurações como sugestão (mais ou menos o exemplos abaixo), ajudaria a muitos, principalmente nesse início de implementação das mudanças. Minha sugestão seria que vocês colocassem (talvez em outro tópico, não sei) algo mais ou menos como abaixo. Obs. 1) A ideia é configurar tudo sem usar Capicom; 2) A opção em destaque é a sugerida para se utilizar em cada caso. As opções que eu destaco são apenas para se entender minha sugestão: 1) Para quem usava (até antes das mudanças) A3 com Capicom: a) ACBrNFe1.Configuracoes.Geral.SSLLib := libNone, libOpenSSL, libCapicom, libCapicomDelphiSoap, libWinCrypt, libCustom ACBrNFe1.Configuracoes.Geral.SSLCryptLib := cryNone, cryOpenSSL, cryCapicom, cryWinCrypt c) ACBrNFe1.Configuracoes.Geral.SSLHttpLib := httpNone, httpWinINet, httpWinHttp, httpOpenSSL, httpIndy d) ACBrNFe1.Configuracoes.Geral.SSLXmlSignLib := xsNone, xsXmlSec, xsMsXml, xsMsXmlCapicom 2) Para quem usava (até antes das mudanças) A1 com Capicom: a) ACBrNFe1.Configuracoes.Geral.SSLLib := libNone, libOpenSSL, libCapicom, libCapicomDelphiSoap, libWinCrypt, libCustom ACBrNFe1.Configuracoes.Geral.SSLCryptLib := cryNone, cryOpenSSL, cryCapicom, cryWinCrypt c) ACBrNFe1.Configuracoes.Geral.SSLHttpLib := httpNone, httpWinINet, httpWinHttp, httpOpenSSL, httpIndy d) ACBrNFe1.Configuracoes.Geral.SSLXmlSignLib := xsNone, xsXmlSec, xsMsXml, xsMsXmlCapicom 3) Para quem usava (até antes das mudanças) A1 com openSSL: a) ACBrNFe1.Configuracoes.Geral.SSLLib := libNone, libOpenSSL, libCapicom, libCapicomDelphiSoap, libWinCrypt, libCustom ACBrNFe1.Configuracoes.Geral.SSLCryptLib := cryNone, cryOpenSSL, cryCapicom, cryWinCrypt c) ACBrNFe1.Configuracoes.Geral.SSLHttpLib := httpNone, httpWinINet, httpWinHttp, httpOpenSSL, httpIndy d) ACBrNFe1.Configuracoes.Geral.SSLXmlSignLib := xsNone, xsXmlSec, xsMsXml, xsMsXmlCapicom Obrigado!

Bom dia, Também estou um pouco perdido ainda, pois são várias as mudanças... Mas esse erro aí em específico eu tive também e a execução do install resolveu. Abraços.

Bom dia Italo, Beleza. Então, atualmente, o nome sendo salvo atualmente é mesmo NumNota + Serie + "-nfse.xml", certo? Mas, com absoluta certeza, até fevereiro era saldo sem a série. Algo mudou nos fontes. Tenho certeza disso, pois minhas rotinas de recuperação do arquivo sempre foram buscando o arquivo com o nome SEM a serie. Mas tranquilo, se agora é assim, vou mudar minhas rotinas e resolvido. Obrigado!

Bom dia, Houve alguma mudança no nome que o Acbr atribuiu ao arquivo XML final da nota. Não sei dizer desde quando (faz alguns dias), mas estava salvando assim: NumNota + "-nfse.xml" (ex NF 243: 243-nfse.xml). Agora está salvando assim: NumNota + Serie + "-nfse.xml" (ex NF 243: 243UNICA-nfse.xml). Houve mesmo uma mudança no Acbr ou que pode estar gerando essa mudança de nova do XML da nota? Provedor: Fiorilli. Obrigado!

Bom dia Juliomar, No manual diz: REGISTRO DETALHE - SEGMENTO P REMESSA Posição: 045 –057 Tamanho: 013 REGISTRO DETALHE - SEGMENTO T RETORNO Posição 041 –053 Tamanho: 013 Obrigado

Boa noite, Estou fazendo tratamento do retorno Santander e me deparei com uma situação que gerou uma dúvida: No create do TACBrBancoSantander, na linha 88 da ACBrBancoSantander.pas, o tamanho máximo do nosso número está com 12. Vide abaixo constructor TACBrBancoSantander.create(AOwner: TACBrBanco); begin inherited create(AOwner); fpDigito := 7; fpNome := 'Santander'; fpNumero := 033; fpTamanhoMaximoNossoNum := 12; fpTamanhoCarteira := 3; fpTamanhoConta := 11; end; Já na rotina de leitura do arquivo de retorno desse mesmo banco, linha 917 da ACBrBancoSantander.pas, está assim ACBrBanco.TamanhoMaximoNossoNum := 13; Não deveriam ser iguais esses valores do tamanho máximo do nosso número? Obrigado

É isso mesmo BigWings...o Windows desatualizado tinha como fim do horário de verão o dia 12 de fevereiro, o que gerou toda essa situação... Obrigado!

Bom dia, Estou tendo esse erro (Data-Hora de Emissão Posterior ao Horário de Recebimento) desde terça-feira. Pode ser coincidência, mas foi justamente após atualizar os fontes do Acbr. Em princípio não pode ser problema de configuração da máquina do usuário (UTC, por exemplo), pois ocorre com vários clientes onde estava tudo ok antes de atualizar. A data/hora do Windows está correta. Anexo o XMLs de envio e retorno que está dando rejeição. Alguma dica? Obrigado. 2906-env-lot.xml 2906-pro-lot.xml 15170224585672000174650010000029031100731059-nfe.xml 15170224585672000174650010000029031100731059-ped-sit.xml 15170224585672000174650010000029031100731059-sit.xml

Bom dia, De fato Italo, eu me equivoquei. Na verdade eu estava colocando o código errado do serviço e, não sei porque cargas d'agua, o WS retornava um erro do campo discriminação. Quando for usuário do proRJ, alterei o sistema para transmitir o RPS pelo .Enviar. Nos testes iniciais que fiz deu tudo certo. Vamos agora ver à campo. Obrigado pela ajuda!

Bom dia Italo, O problema é que quando transmite por lote (ACBrNFSe1.Enviar(VNumLote)), ele NÃO permite que seja informado o Servico.Discriminacao. E quando se utiliza a opção de enviar um RPS (ACBrNFSe1.Gerar(VNumRPS)) esse campo (Servico.Discriminacao) é obrigatório. Por isso optei por fazer tudo pelo "Gerar", mas aí emperrou. Pelo visto será necessário ter uma rotina de alimentação dos dados diferente para cada provedor. Eu entrei em contato com o provedor conforme você sugeriu e relatei a situação. A resposta deles foi: "Não existe nenhum problema no funcionamento do sistema e não ocorreram alterações em schemas. Quando há alguma alteração técnica relevante, e que vá impactar diretamente ao contribuinte, o mesmo recebe mensagens antes da alteração ser disponibilizada em produção. Verifique o seu sistema, se realmente está se conectando e enviando arquivos e se está recebendo arquivo de retorno que o sistema da Nota Carioca devolve. Todas as informações para a integração do seu sistema com o sistema de NFS-e da Prefeitura (Nota Carioca) estão disponibilizados nos "Manuais de Utilização do Web Service (Modelo Nacional)" disponíveis no setor de Manuais de Ajuda do site da Nota Carioca. Além de manuais, é possível baixar os schemas e exemplos dos XML para a comunicação." Obrigado!