Assinar Xml Cte Com Openssl

[Diego R]

Boa tarde.

Estou desenvolvendo uma aplicação para emissão de CTe, porém após assinar o XML ele está ficando invalido, com pontos de interrogação.

Estamos utilizando o ACBR com o OpenSsl. Instalei o ACBR através do instalador. O ambiente é Delphi 2010 com todos updates feitos,Windows 7 64bits e com os fontes do ACBR atualizados pelo SVN.

Fiz testes em um ambiente com windows 32bits e com delphi Xe2 também... e ocorre o mesmo problema.

 

O XML fica invalido ao entrar na função " CTeUtil.sign_file ".

 

Não utilizando o OpenSsl com os certificados instalados funciona.... Agradeço caso alguém possa me ajudar.

 

Anexei o XML antes de ser assinado e depois de ser assinado.

DepoisAssinar.xml

AntesAssinar.xml

Editado 22 Março, 2013 por Diego R

[Juliomar Marchetti]

Italo

Aqui se encontra a correção acima descrita pelo Diego

[Italo Giurizzato Junior]

Boa noite Juliomar,

 

Já esta disponivel a correção.

[Diego R]

Bom dia.

Agora estou com problema no Validar XML quando um dos clientes é ISENTO, acredito que seja algum problema no Schema.

Quando envio o mesmo XML com o Capicon valida.

 

O erro que retorna é:

1824 - Element '{http://www.portalfiscal.inf.br/cte}IE': 'ISENTO' is not a valid value of the local atomic type.

 

Em anexo o XML.

 

Agradeço desde já.XML.xml

 

[Italo Giurizzato Junior]

Bom dia Diego,

 

Por se tratar de uma pessoa fisica e não juridica, atribui vazio ao IE em vez de "ISENTO".

[Diego R]

Bom dia Italo, vou testar... porém com o Capicom eu mando ISENTO e valida.

 

Obrigado

[Diego R]

Bom dia.

Se eu mando IE vazio o erro é o seguinte:

1871 - Element '{http://www.portalfiscal.inf.br/cte}xNome': This element is not expected. Expected is ( {http://www.portalfiscal.inf.br/cte}IE ).

 

No XML nao cria a tag IE.

Em anexo o XML.

 

cte.xml

[Italo Giurizzato Junior]

Boa tarde Diego,

 

Favor atualizar os fontes e testar novamente.

[Diego R]

Vou atualizar Italo.

O problema era em algum schema?

[Italo Giurizzato Junior]

Diego,

 

Pela mensagem de erro, ele estava esperando a tag IE e ele encontrou xNome.

Com a alteração que fiz é para resolver o problema.

[Diego R]

Italo, agora está processando os conhecimentos com CPF mandando vazio.

Porém quando mando um CNPJ que é ISENTO ta dando erro ao validar:

 

1824 - Element '{http://www.portalfiscal.inf.br/cte}IE': 'ISENTO' is not a valid value of the local atomic type.

 

Obs.: Com o Capicon está funcionando enviar ISENTO tanto CNPJ como CPF!

Agora com o OPENSSL estava dando o erro de Isento em um CPF (que você corrigiu), dai agora testei um CNPJ com a IE ISENTO e retornou erro ao validar o xml também, não seria algum problema com o schema?

 

 

Em anexo o XML.

 

 

-cte.xml

[Italo Giurizzato Junior]

Diego,

 

Agora so resta o schema, pelo que vi você esta informando a palavra "ISENTO" no campo IE do Destinatário.

 

A tag IE do destinatário é do tipo TIeDest e segundo o schema: tiposGeralCTe_v1.04 é para aceitar a palavra ISENTO, veja:

 

   <xs:pattern value="[0-9]{0,14}|ISENTO|PR[0-9]{4,8}"/>
 

Faça o seguinte teste, altere o shema invertendo a posição da seguinte forma:

 

   <xs:pattern value="ISENTO|[0-9]{0,14}|PR[0-9]{4,8}"/>
 

[Diego R]

A principio deu certo Italo.

Estarei fazendo testes e qualquer problema voltamos a conversar.

 

Obrigado!!

[Diego R]

Bom dia Italo

O problema de validação do Schema foi resolvido, muito obrigado.

 

A questão agora é que estou com outro problema utilizando o OpenSsl que acredito que já foi corrigido na NFe utilizando o OpenSsl.

 

Vou tentar explicar:

A primeira vez que eu crio o componente TACBrCTe ele cria certo e não tem problema...  depois de destruir ele e tentar criar novamente retorna o erro:

 

---------------------------

 EAccessViolation with message 'Access violation at address 77798DC9 in module 'ntdll.dll'. Write of address 00000014'.

---------------------------

 

Estive analisando os fontes e localizei o seguinte:

O erro está acontecendo na unidade CTeUtil.InitXmlSec em xmlInitParser(). (porém como comentei anteriormente só ocorre a segunda vez que passa por ali)

 

Verifiquei que na unidade ACBRCTe a função Create tem a seguinte instrução:

  {$IFDEF ACBrCTeOpenSSL}

     CteUtil.InitXmlSec ;

  {$ENDIF}

 

e já na unidade ACBrNFe está da seguinte forma:

  {$IFDEF ACBrNFeOpenSSL}

    if FConfiguracoes.Geral.IniFinXMLSECAutomatico then

      NotaUtil.InitXmlSec ;

  {$ENDIF}

 

 

Estou procurando uma solução, mas, se puder verificar isto para mim agradeço.

 

Obrigado!

[Diego R]

Boa tarde, problema resolvido:

- Primeiro alterei as unidades AcbrCTe, ACBrCteUtil, e ACBrCTeConfiguracoes para ter a variável FConfiguracoes.Geral.IniFinXMLSECAutomatico igual a NFe.

- Segundo, na minha aplicação, após criar o componente TACBrCTe eu seto a variavel FConfiguracoes.Geral.IniFinXMLSECAutomatico para False.

 

Desta maneira está funcionando, estarei realizando vários testes. Se encontrar alguma outra situação posto aqui!

 

Obrigado pela atenção de todos.

[Italo Giurizzato Junior]

Boa tarde,

 

Assim que você terminar os testes e concluir que essas alterações são validas, por favor poste as unit como anexo no fórum para que possamos realizar um merge e disponibilizar para os demais colegas.

[Diego R]

Boa tarde Italo.

Segue as unit que alterei conforme comentei em post anterior.

 

Obrigado pela atenção.

ACBrCTe.pas

ACBrCTeConfiguracoes.pas

ACBrCTe.pas

ACBrCTeConfiguracoes.pas

[ncc.star]

Boa tarde.

Migrei para o Trunk2 e estou testando utilizando openssl (sempre usei capicom) e tive o mesmo problema relatado pelo Diego.

Quando a IE do destinatário for ISENTO ocorre o erro "Elemento 'IE': 'ISENTO' is not a valid value of the local atomic type."

Já utilizando Capicom valida normalmente.

Se alterar o schema invertendo a posição da seguinte forma:

   <xs:pattern value="ISENTO|[0-9]{0,14}|PR[0-9]{4,8}"/>

autoriza normal.

É só esse caso que ocorre esse problema, ou tem mais coisas a alterar no schema quando usa OpenSSL?

Seria o caso de ter duas versões de schemas?

 

 

 

[Italo Giurizzato Junior]

Bom dia ncc,

Estou achando que seria a solução, ter dois schemas uma para OpenSSL e outro para o Capicom.

[ncc.star]

Em anexo o arquivo XSD alterado. Acredito que poderia ser colocado no Trunk2, pelo que eu vi na NF-e foi feito a mesma coisa.

• O que diferencia a validação dos dados utilizando a versão Capicom e OpenSSL?
• Essa diferença poderia afetar outras verificações?

Meu receio é que usando OpenSSL teria outros erros que não ocorreriam na versão Capicom, a exemplo do ISENTO.

tiposGeralCTe_v2.00_OPENSSL.xsd

tiposGeralCTe_v2.00-OPENSLL.xsd

[ncc.star]

Com o MDF-e acontece o mesmo. Segue o XSD alterado do MDF-e.

Envio também novamente XSD do CT-e. Não sei porque antes anexou 2 arquivos, eu tinha excluído 1.

 

 

tiposGeralMDFe_v1.00-OPENSSL.xsd

tiposGeralCTe_v2.00-OPENSSL.xsd

[Italo Giurizzato Junior]

Bom dia,

Muito obrigado pela colaboração, já esta disponível.

[carlosmarian]

Na versão trunk2 usando OPENSSL tivemos problemas nas TAGs abaixo:

1824 - Element '{http://www.portalfiscal.inf.br/cte}tpMed': [^] 'un' is not a valid value of the local atomic type.

1824 - Element '{http://www.portalfiscal.inf.br/cte}tpMed': [^] 'Kg' is not a valid value of the local atomic type.

Com a alteração do arquivo conforme citado acima o erro na TAG IE foi resolvido mas apareceu este novo erro.

 

 

[carlosmarian]

Post acima resolvido.

Obrigado.

[carlosmarian]

22 horas atrás, carlosmarian disse:

Post acima resolvido.

Obrigado.

 

tiposGeralCTe_v2.00_OPENSSL.xsd