Ir para conteúdo
  • Cadastre-se

dev botao

MDFe - Rejeição se Não informar IE do proprietário


Ver Solução Respondido por Rafael Dias,
  • Este tópico foi criado há 1950 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

  • Membros Pro

Boa tarde,

Há algum tempo tive problemas de tag de MDFe que gerava o erro de validação pelo schemas do campo do número da rua.

Segundo informações o problema estava no tiposGeralMDFe_v3.00.xsd disponibilizado pela receita que não validava esse dado (nr da rua) de forma correta.

A solução para contornar esse problema na época foi utilizar um .xsd modificado pelo ACbr, qual seja: 
renomear o tiposGeralMDFe_v3.00-OPENSSL.xsd para tiposGeralMDFe_v3.00.xsd.

Aquele erro e respectiva solução estão detalhados nesse post: https://www.projetoacbr.com.br/forum/topic/44499-erro-no-n%C3%BAmero-da-rua-mdfe/

Muito bem, o que está ocorrendo agora é um erro parecido e que não aceita CPF para proprietário do veículo (tag rodo.veicTracao.prop.CNPJCPF). 
Ele até aceita CPF, mas aí exige a IE (rodo.veicTracao.prop.IE). Se deixar sem IE dá o erro "Element '{Http://www.portalfiscal.inf.br/mdfe}IE' is a not valid value...".
Se colocar "ISENTO" na IE, aí passa, mas não estaria correto, pois CPF não é isento de IE. Ele simplsmente não tem IE.

Fiz uma tentativa e deu certo: ao invés de renomear o arquivo tiposGeralMDFe_v3.00-OPENSSL.xsd, utilizei o arquivo tiposGeralMDFe_v3.00.xsd original da SEFAZ. 
Com esse procedimento o erro não mais ocorreu.

Imagino que o problema inicial (aquele lá do outro post) que comentei acima, ou seja, que o .xsd da SEFAZ que estava com problema, que talvez tenha sido corrigido agora e, nesse caso, não precisaríamos mais do tiposGeralMDFe_v3.00-OPENSSL.xsd, correto?

Obrigado.

Valdir Dill

Rio de Janeiro - RJ

 

 

Link para o comentário
Compartilhar em outros sites

Peo que vi no SCHEMA este campo é obrigatório.

IE.png

E ele aceita ser vazio, o IE Correto e ISENTO.

IE.png

e isso esta desta maneira nos 2 arquivos mencionados por você.

e nos fontes já prevê a geração do campo como vazio.

    if MDFe.Rodo.veicTracao.Prop.IE <> '' then
    begin
      if MDFe.Rodo.veicTracao.Prop.IE = 'ISENTO' then
        Gerador.wCampo(tcStr, '#15', 'IE ', 00, 14, 1, MDFe.Rodo.veicTracao.Prop.IE, DSC_IE)
      else
        Gerador.wCampo(tcStr, '#15', 'IE ', 02, 14, 1, OnlyNumber(MDFe.Rodo.veicTracao.Prop.IE), DSC_IE);
      if (FOpcoes.ValidarInscricoes) then
        if not ValidarIE(MDFe.Rodo.veicTracao.Prop.IE, MDFe.Rodo.veicTracao.Prop.UF) then
          Gerador.wAlerta('#15', 'IE', DSC_IE, ERR_MSG_INVALIDO);
    end
    else
     Gerador.wCampo(tcStr, '#15', 'IE ', 00, 14, 1, '', DSC_IE);

Então provavelmente você deve informar o campo como vazio.

 

  • Curtir 1

 

Link para o comentário
Compartilhar em outros sites

  • Membros Pro
24 minutos atrás, Amarildo de Matos disse:

boa tarde..

o que o rafael falou ta certo. tem de informar nem que seja em branco.

caso nao der certo,mande para analise o xml gerado e o log tambem.. pode ser?..

2018-11-24_1753

 

Em anexo estão os arquivos. Se puder analisar.

No final do nome do arquivo (após a extensão) informei qual arquivo é gerado com .xsd da SEFAZ e qual é com o .xsd openSSL.

Também envio o arquivo do erro.

Eu analisei os XMLs e parece que são iguais.

Obs.: o erro ocorre na hora do ACBrMDFe1.Manifestos.Validar;

Obrigado.

 

 

26181113971229000115580010000007151016422209-mdfe ComXsdOpenSSl.xml

26181113971229000115580010000007151016422209-mdfe ComXsdSEFAZ.xml

ErroIE.png

Valdir Dill

Rio de Janeiro - RJ

 

 

Link para o comentário
Compartilhar em outros sites

  • Membros Pro
3 minutos atrás, Amarildo de Matos disse:

so nao entendi uma coisa..quais dos dois xml é o que quer que eu veja o primeiro ou o segundo?

 

Tanto faz. Eu só mandei dois arquivos porque um deles eu gerei com o .xsd da SEFAZ gravado no meu path Schemas. E o outro eu gerei quando estava o .xsd openSSL. No nome dos arquivos (no final) eu coloquei essa informação. Veja o print anexo.

Ao que parece, gerar o xml ele gera ambos exatamente igual. Acho que para montar o XML ele não usa o .xsd, certo? Então se você pegar qualquer um dos arquivos e, tentar fazer a validação com o tiposGeralMDFe_v3.00-OPENSSL.xsd  vai dar o erro. 

 

Arquivos.png

Valdir Dill

Rio de Janeiro - RJ

 

 

Link para o comentário
Compartilhar em outros sites

  • Moderadores

ha..entendi

vou analizar os dois entao..

aguarde..

agora.. me mande tambem o log, que o acbr, gera.. com isso vai facilitar aqui minha vida]

 

enquando estou olhando o seu xml, estou te mandando um exemplo meu.. 

43181103850874000126580010000001351000003370-mdfe_trasmitido.xml

Link para o comentário
Compartilhar em outros sites

  • Moderadores

Uma das coisas, que vi.. que esta faltando a informacao do RNTRC. se nao tiver, tem de mandar zerado..

 

      <infModal versaoModal="3.00">
        <rodo>
          <infANTT>
            <RNTRC>00000000</RNTRC>

2018-11-24_1836

 

olhe tambem 

esta faltando o renavam..

<veicTracao>
            <placa>AKG8782</placa>
            <RENAVAM>783209533</RENAVAM>
            <tara>10</tara>
            <condutor>
              <xNome>AMARILDO DE MATOS</xNome>
              <CPF>38021528087</CPF>
            </condutor>
            <tpRod>06</tpRod>
            <tpCar>00</tpCar>
            <UF>RS</UF>
          </veicTracao>
        </rodo>

2018-11-24_1838

 

Assim.. acho que é isso.. acerte esses detalhes. refaça o xml, e transmita.. caso de erro, alem de me mandar o Xml, me mande tambem os Logs.

e aguardo retorno..valeu

Link para o comentário
Compartilhar em outros sites

  • Membros Pro
20 minutos atrás, Amarildo de Matos disse:

Uma das coisas, que vi.. que esta faltando a informacao do RNTRC. se nao tiver, tem de mandar zerado..

 

      <infModal versaoModal="3.00">
        <rodo>
          <infANTT>
            <RNTRC>00000000</RNTRC>

2018-11-24_1836

 

olhe tambem 

esta faltando o renavam..

<veicTracao>
            <placa>AKG8782</placa>
            <RENAVAM>783209533</RENAVAM>
            <tara>10</tara>
            <condutor>
              <xNome>AMARILDO DE MATOS</xNome>
              <CPF>38021528087</CPF>
            </condutor>
            <tpRod>06</tpRod>
            <tpCar>00</tpCar>
            <UF>RS</UF>
          </veicTracao>
        </rodo>

2018-11-24_1838

 

Assim.. acho que é isso.. acerte esses detalhes. refaça o xml, e transmita.. caso de erro, alem de me mandar o Xml, me mande tambem os Logs.

e aguardo retorno..valeu

Certo, esses dados realmente não constam no XML.

Mas se olharmos o manual de integração do MDFe veremos que eles não são obrigatórios (ocorr. 0-1). Tanto é que o usuário envia o MDFe sem esses dados e é aceito sem problemas.

Lembre que o erro que está ocorrendo é de validação (antes de enviar) e não de rejeição. Se eu utilizar o xsd da SEFAZ, o Acbr vai validar e enviar o XML sem problemas. Se eu utilizar o .xsd openSSL o Acbr não passa na validação. Ocorre o erro relacionado a IE que mencionei no início.

Não sei se ajuda. Não entendo muito de expressões regulares. Mas analisei os dois .xsd e encontrei uma única diferença entre eles, que está na linha 565. 

linha 565 do .xsd openSSL
<xs:pattern value="[!-ÿ]{1}[ -ÿ]*[!-ÿ]{1}|[!-ÿ]{1}"/>

linha 565 do .xsd SEFAZ
<xs:pattern value="[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}"/>

Então, por questão de lógica, se utilizando um arquivo .xsd o XML é validado e utilizando o outro .xsd, o XML não é validado, então imagino que a causa da validação/não validação esteja nessa linha, ou não?

 

Valdir Dill

Rio de Janeiro - RJ

 

 

Link para o comentário
Compartilhar em outros sites

So complementando os XSD não tem nada haver com a geração eles são usados apenas para validação é estranho o que você relata visto que os dois XSD são iguais nesta parte da validação, ou seja idependente de qual XSD você usa para validar não muda a forma que gera o XML, o no caso o XML gerado pelo componente esta valido.

Sem título.png

Me responde qual método de assinatura esta usando ? xsLibXml2 ?

Teste com este XSD tiposGeralMDFe_v3.00-OPENSSL.rar

 

Link para o comentário
Compartilhar em outros sites

  • Membros Pro
5 horas atrás, Rafael Dias disse:

So complementando os XSD não tem nada haver com a geração eles são usados apenas para validação é estranho o que você relata visto que os dois XSD são iguais nesta parte da validação, ou seja idependente de qual XSD você usa para validar não muda a forma que gera o XML, o no caso o XML gerado pelo componente esta valido.

Sem título.png

Me responde qual método de assinatura esta usando ? xsLibXml2 ?

Teste com este XSD tiposGeralMDFe_v3.00-OPENSSL.rar

Bom dia,

Sim, como comentei no post inicial, é justamente com o arquivo tiposGeralMDFe_v3.00-OPENSSL.xsd que está ocorrendo o erro. Basta você pegar o XML que envie e testar a validação. 

Usando tiposGeralMDFe_v3.00-OPENSSL.xsd dá erro. Usando tiposGeralMDFe_v3.00.xsd, não dá erro.

Sim, uso xsLibXml2.

Obrigado.

Editado por valdirdill

Valdir Dill

Rio de Janeiro - RJ

 

 

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Bom dia,

Por favor ignore meu comentário sobre a possibilidade da causa do erro estar no fato da diferença na linha 565 dos arquivos .xsd (SEFAZ e openSSL).
Fiz mais testes e descobri o ponto que gera o erro de validação.
Está linha 401 dos dois arquivos .xsd.

No arquivo tiposGeralMDFe_v3.00.xsd da SEFAZ, o original, a linha 401 está assim:
<xs:pattern value="[0-9]{0,14}|ISENTO|PR[0-9]{4,8}"/> 

No arquivo tiposGeralMDFe_v3.00-OPENSSL.xsd modificado pelo Acbr, a linha 401 está assim:
<xs:pattern value="ISENTO|[0-9]{0,14}|PR[0-9]{4,8}"/>

Fiz um teste e mudei a linha 401 no arquivo openSSL, deixando-a igual a linha 401 do .xsd da SEFAZ e, com isso, não ocorreu mais o erro. Então, com certeza o ponto de disparo do erro é nessa linha.
Só não sei porque, hehe! Pelo que notei, há apenas uma inversão da ordem na posição do "ISENTO", mas como comentei antes não entendo muito de ER. 

Obrigado!

Valdir Dill

Rio de Janeiro - RJ

 

 

Link para o comentário
Compartilhar em outros sites

  • Solution

você não prestou atenção mais eu ja tinha feito esta modificação e coloquei em anexo no meu ultimo post.

Sobre este erro eu tava lendo e a LibXml2 tem problemas com expressões regulares por isso temos que alterar a linha 565 e este erro da linha 401 deve ser pelo mesmo motivo vou enviar o arquivo alterado para o repositório.

 

Link para o comentário
Compartilhar em outros sites

  • Membros Pro
2 horas atrás, Rafael Dias disse:

você não prestou atenção mais eu ja tinha feito esta modificação e coloquei em anexo no meu ultimo post.

Sobre este erro eu tava lendo e a LibXml2 tem problemas com expressões regulares por isso temos que alterar a linha 565 e este erro da linha 401 deve ser pelo mesmo motivo vou enviar o arquivo alterado para o repositório.

Boa tarde,

Ah certo, agora entendi.

Na verdade quando vi seu anexo tiposGeralMDFe_v3.00-OPENSSL.rar imaginei que você estaria me sugerindo para fazer o mesmo teste  com o mesmo arquivo que eu já tinha feito várias vezes e comentei nas idas e vindas das minhas respostas deste post. Como você não mencionou que esse seria um tiposGeralMDFe_v3.00-OPENSSL.xsd modificado, entendi que não teria sentido fazer o teste novamente, hehe!

Mas acho que agora está tudo esclarecido e, com seu upload, também vai ficar tudo corrigido.

Obrigado.

  • Curtir 1

Valdir Dill

Rio de Janeiro - RJ

 

 

Link para o comentário
Compartilhar em outros sites

  • Este tópico foi criado há 1950 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.
Visitante
Este tópico está agora fechado para novas respostas
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.