Ir para conteúdo
  • Cadastre-se

wendelswl

Membros
  • Total de ítens

    27
  • Registro em

  • Última visita

Reputação

5 Neutro

Sobre wendelswl

  • Rank
    Membro

Contact Methods

  • Website URL
    http://www.swlsoft.com.br

Profile Information

  • Sexo
    Masculino
  • Localização
    Santo Antonio de Jesus-BA

Últimos Visitantes

439 visualizações
  1. Me deram a mesma resposta, estou insistindo com eles. Já enviei 3 e-mails e a resposta é a mesma. Acho que só vão resolver o problema quando mais pessoas reclamarem.
  2. Seguem os arquivos conforme solicitado. 29181209029006000166550010000011871015341068-sit.xml 29181209029006000166550010000011871015341068-ped-sit.xml 29181209029006000166550010000011871015341068-nfe.xml
  3. Estou com o mesmo problema, e a SEFAZ insiste que o erro está conosco. Enviei novamente o e-mail para eles com todas as informações, caso tenha algum retorno positivo posto aqui.
  4. Boa tarde. Fiz atualização hoje 14/06 e o problema foi sanado.
  5. Bom dia a todos, André, de acordo este post que estou acompanhando só consegui êxito com certificado A1 e Windows Server 2008 R2/2012 R2 fazendo o seguinte procedimento: ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicom; ACBrNFe1.Configuracoes.Geral.SSLLib := libWinCrypt; O colega acima mencionou que dessa forma esta utilizando Capicom e vez de WinCrypt, com essa reversão da revisão 15264 este cenário foi modificado? Nos comentários do Cristiano neste post também vejo uma alternância de TLS para funcionamento em determinados sistemas operacionais, para NF-e 4.0 não seria única e exclusivamente TLS 1.2? Agradeço antecipadamente o empenho de todos envolvidos, está sendo bastante produtivo para nós os dois posts.
  6. Cleyton e Marcelo, aqui deu certo tb, só que tive que definir no ACBr.inc o {.$DEFINE DFE_SEM_CAPICOM} novamente, pois já tinha retirado o suporte a capicom da aplicação. Obrigado, temporariamente vou utilizar desta forma.
  7. Daniel, primeiramente obrigado pela resposta. Se não me engano OpenSSL só funciona com certificado A1 (estou testando com certificado A1 inicialmente), mas neste caso eu teria problemas com A3, tenho clientes em produção com o mesmo. O curioso é que até a última atualização estava funcionando no próprio Windows Server 2012 R2, cheguei a emitir algumas NF-e`s 4.0 através do mesmo. Não tenho documentado a revisão da versão anterior. Vou continuar na busca aqui por soluções e qualquer coisa compartilho a solução, agradeço a todos pelas respostas.
  8. Fiz atualização no Windows Server 2008 R2 e Windows Server 2012 R2, nos dois casos o erro continua mesmo após os updates. Caso alguém tenha alguma dica adicional agradeço.
  9. Bom dia Marcelo, tinha feito atualização dos componentes há uns 15 dias e estava emitindo normalmente, após a atualização que fiz no dia 12/06 começou a apresentar este erro. Mais uma vez obrigado pelo feed Felipe, já tinha efetuado a configuração no componente. Windows ainda sendo atualizado, posto o resultado.
  10. Opa Frederico, bom dia. Estou utilizando o WinCrypt sim. Estou baixando os updates do Windows Server 2008 R2 neste momento, assim que concluir testo e posto os resultados.
  11. Bom dia Felipe, não tenho mais a dependência da Capicom, fiz isso nas diretivas contidas no ACBr.inc, a marcação de TLS 1.2 seria essa no componente ACBrNFe1.SSL.SSLType := LT_TLSv1_2 ou no navegador? Só um detalhe, só acontece no windows server 2008 r2, no windows 10 funciona perfeitamente. Agradeço antecipadamente,
  12. Estou enfrentando o mesmo problema, fiz atualização hoje. 12/06/2018.
  13. Pessoal, obrigado. O erro era no campo cNF do meu XML. Podem fechar o tópico e desculpem-me pelo transtorno..
  14. Prezados, bom dia. Percebi uma mudança após atualizar a versão do ACBr na seguinte situação: Tenho um determinado XML sem assinar, faço um LoadFromFile pelo componente e logo após chamo o método Assinar, percebi que nesta situação sempre é gerada uma nova chave de acesso para a nota fiscal, mesmo já constando uma chave de acesso no XML anterior. Na situação em que há rejeição é necessário modificar as propriedades do componente, assinar e transmitir novamente, e o ideal seria que a chave de acesso não fosse alterada neste procedimento, visto que, trata-se da mesma nota fiscal. Percebi pelos fontes que o método Assinar sempre chama o método GerarXML, que passa pelo código abaixo sempre gerando uma nova chave de acesso. Os colegas estão tendo esta dificuldade? Sempre fiz desta maneira e a chave nunca era alterada, há algo de errado neste fluxo? function TNFeW.GerarXml: Boolean; var chave: String; Gerar: Boolean; xProtNFe : String; xCNPJCPF : string; begin Gerador.ListaDeAlertas.Clear; Usar_tcDe4 := (NFe.infNFe.Versao >= 3.10); Versao := Copy(NFe.infNFe.VersaoStr, 9, 4); xCNPJCPF := nfe.emit.CNPJCPF; if not EstaVazio(nfe.Avulsa.CNPJ) then xCNPJCPF := nfe.Avulsa.CNPJ; chave := GerarChaveAcesso(nfe.ide.cUF, nfe.ide.dEmi, xCNPJCPF, nfe.ide.serie, <-- AQUI nfe.ide.nNF, StrToInt(TpEmisToStr(nfe.ide.tpEmis)), nfe.ide.cNF, nfe.ide.modelo); Agradeço por alguma resposta antecipadamente.
×
×
  • Criar Novo...