Problemas envio da NFE: 588 - Rejeição: não é permitida a presença de caracteres

Dica: Pegue o XML de envio e use o ALTOVA para bater contra o SCHEMA.

A/C montano ,

Bom dia, cara não conheço o ALTOVA  , você poderia me dar uma dica de como fazer para validar o XML com este ALTOVA ?

Obrigado,
Dankshit

Claro, baixe o ALTOVA xml spy, abra o xlm com ele, sem o envelope somente o xml.

Depois va em DTD/Schema -> assign SCHEMA e escolha o schema que vc deseja fazer a comparacao.

apos isso aperte F8 e ele mostrara se o xml é valido ou nao.

os schemas vc pega no site da fazenda.

dankshit, vc está transmitindo para um servidor de homologação ou de produção?
Estou com o mesmo problema apenas no servidor de homologação.

Este erro é de rejeição na consulta do recibo dado pelo servidor da fazenda.
Por isso acredito não ser problema de schema.
Acho que esse problema deve estar relacionado a lentidão nos servidores do dia 06/10/10 e também a manutenção que será feita nos mesmos no próximo domingo.

Se alguém puder dar uma luz, pois está difícil de conseguir um suporte do pessoal do governo.
Grato

Estou exatamente com o mesmo problema, durante a lentidão no servidor de produção (versão 1.10) as notas no servidor de homologação (versão 2.00) começaram a voltar com o erro
588 - Rejeição: Não é permitida a presença de caracteres de edição no início/fim da mensagem ou entre as tags da mensagem

E eu achando que eu tinha feito alguma m…
Pelo jeito deve ter a ver com a manutenção do domingo mesmo.
Mesmo pq o erro não está previsto no manual.

E não é problema com o scheema, é validação com eles lá

Depois da lentidão de ontem em produção, não duvido nada que isso seja bug no ambiente de homologação.

PS: é uma m… ser pioneiro num bug, ainda bem que achei alguém q teve o mesmo problema, isso quer dizer q não sou louco.

Só para constar, eu acertei o título deste post para não ficar muito comprido. (Tirei aquele montão de pontinhos.)
É que há um bug no fórum que faz com que alguém que queira dar um “reply” na sua mensagem acabe tomando uma exceção que basicamente diz “o título ficou muito comprido para inserir a resposta no banco”.

Pessoal boa tarde estou com o mesmo problema que vocês:
588 - Rejeição: Não é permitida a presença de caracteres de edição no início/fim da mensagem ou entre as tags da mensagem
alguém teve alguma novidade??

Pelo sistema gratuito da Sefaz, mesmo em homologação, funciona normalmente!!

A/C Fórum,

Bom dia pessoal, estou enviando em ambiente de homologação, em produção tá tudo certo, em todos os meus cliente tá dando o mesmo erro quando envia em homologação, mais produção, ainda bem tá funcionando.

Vamos esperar essa manutenção de domingo pra ver como que fica na segunda, fico mais aliviado em saber que não é somente comigo esta rejeição.

Obrigado a todos.
Dankshit

Pessoal bom dia.
Também estou tendo o mesmo problemas.
Porém é só no servidor de SP, nos outros estados está validando normalmente.
Se alguém tiver mais alguma informação para nos ajudar, agradecemos.
Obrigado.

Boa tarde.
Estou com o mesmo problema.

Vocês chegaram a fazer o seguinte teste:

• Importar o XML gerado e assinado para dentro do emissor gratuito.
• enviar o xml pelo emissor gratuito, sem valida-lo ou assina-lo novamente.

Com este teste aqui comigo retornou o mesmo erro 588.

Se (no emissor gratuito):

• editar a nota fiscal (sem alterar campo algum);
• validar;
• assinar;
• transmitir
  Não retorna o erro 588.

Será que não é alguma anteração no leiaute de consulta da situação da NF-e. consSitNFe?

Daniel.

Mais uma verificação, versão dos Schemas oficiais, em uso atualmente:

Schemas XML NF-e - Pacote de Liberação No. 6g(29/06/2010) (ZIP)
Schemas XML NF-e - Pacote de Liberação No. 5f(29/06/10) (ZIP)
Schemas XML NF-e - Pacote de Liberação No. 6f(01/06/2010) (ZIP)
Schemas XML NF-e - Pacote de Liberação No. 6e(24/03/2010) (ZIP)

No retorno com o erro 588, aparece outra versão: SP_NFE_PL_006h
<verAplic>SP_NFE_PL_006h</verAplic>
<nRec>351000022480939</nRec>
<cStat>588</cStat>
<xMotivo>Rejeição: Não é permitida a presença de caracteres de edição no início/fim da mensagem ou entre as tags da mensagem</xMotivo>
<cUF>35</cUF>
</retConsReciNFe>

Podemos esperar alguma mudança, na regra de validação.

Daniel

Cara esperto, deve ser isso mesmo!

vamos esperar!
embaçado os caras soltarem isso dessa forma
quase morri do coração, tava achando q tava tudo prontinho depois pensei
FU***

Bom dia Pessoal.

Eu enviei um questionamento ao “fale conosco” e eles me pediram que eu enviasse alguns exemplos dos problemas. Fiz o que pediram, gerando xml´s validados na versão 1.10 e logo em seguida, o mesmo envio só que gerando na 2.00. Pois bem, me retornaram a seguinte afirmativa:
Moisés,

[i]Verifique a ordem das informações.

Ver Manual de Integração, versão 4.01, fls. 108:

a) a ordem das informações na TAG Dados da Nf-e é InfNFe, Versão (do layout) e depois ID.

b) no seu arquivo consta InfNFe, ID e depois Versão.

Se o problema não for este por favor enviar novo questionamento ao Fale Conosco que tentaremos sanar o problema o mais rapidamente possível.[/i]

Não entendi direito o que eles quizeram dizer, pois os meus XML´s estão gerados exatamente como o exemplo que eles disponibilizam no site da receita, e se eu pego esse mesmo XML gerado e valido no site do Sefaz-RS, passa perfeitamente sem erros. Acho que se isso fosse uma verdade, daria erro de estrutura “schema” e não um erro que nem no manual está definido. Quanto a isso, também acho estranho pois eles não me responderam o questionamento de não estar descrito o erro no manual 4.0.1, como ele manda eu olhar. Vou fazer mais alguns testes na segunda-feira, epostarei pra vocês o retorno.
Bom FDS a todos.

Mais o que que a ordem tem a ver com esse erro?? e por que só apresenta esse erro nos servidores de homologação de SP??
Acho que isso é falha deles :?
Bom fds amigo e grato pela ajuda

[color=brown]Eu não sei quanto aos outros, mas o SEFAZ aqui de SP é horrível, o atendimento humano deles parece uns robôs, você não consegue tirar uma informação válida deles e ainda tem que esperar em média uns 20min.
[/color]
[color=blue]Semana passada tive problemas ao importar um XML no Emissor deles que da erro, porém eu conseguia validar em todos os outros aplicativos (inclusive no SEFAZ RS), eu até já tinha enviado a nota como teste, e eles diziam que o XML estava errado.
[/color]
[color=red]Quem deu esse poder a essa gente para se acharem Deuses e nós meros subalternos que tem que acatar tudo que eles impõem? Que absurdo! Eles vivem mudando tudo. Da versão 1.0 para a 2.0 mudaram várias coisas e os programadores que se danem, eu acho isso um absurdo.[/color]

Ainda bem que meu cliente não recebeu esse erro, o que ele reclama muito é na demora para enviar as notas e receber o protocolo, demora demais, na homologação vai rapidinho, mas na produção chega a demorar 40min para enviar 5 notas.

Este erro é referente a identação do xml…
Aqui eu fiz o seguinte, criei uma nota pelo Emissor da Secretaria da Fazenda, assinei, exportei, e então fiz o envio pelo meu cliente WebService. Resultado, deu tudo certo.

Reparei que o arquivo XML exportado pelo software deles não tem identação alguma, então fiz o mesmo com o meu, removi a identação e funcionou perfeitamente.

A modificação no meu código foi a seguinte:

transformer.setOutputProperty(OutputKeys.INDENT, "no");

Mais informações de javax.xml.transform em:
http://download.oracle.com/javase/1.4.2/docs/api/javax/xml/transform/OutputKeys.html

Espero ter ajudado… Até+!

[color=red]Só para complementar[/color], precisei tirar todos os espaços entre as tags do XML sem assinatura também.

Percebi (depois q decifrei a msg que o sefaz mandou pro nosso colega ai em cima) que na documentação Pag: 108
a ordem dos atributos id e versão no meu XML está diferente (o que no meu conhecimento sobre XML não deveria interferir em nada, mas blz)
ou seja

Ele gerava assim

<infNFe Id="NFe35000000000000000000000000000000000000000000" versao="2.00">

e segundo a ordem da documentação deveria ser assim

<infNFe versao="2.00" Id="NFe35000000000000000000000000000000000000000000">

Pois bem, eu alterei aqui meu gerador do XML e continuou com o problema, percebi q meu assinador inverte de novo os atributos
então alterei o que nosso outro colega falou
o tal do transformer do meu assinador

transformer.setOutputProperty(OutputKeys.INDENT, "no");

mesmo assim ainda não funcionou, ainda não consegui descobrir o que ta rolando

Se eu descobrir algo novo eu aviso aqui!

Eu fiz isso (tirar todos os caracteres entre as tags) aqui, na verdade já faço!
E ainda não resolveu, eu devo estar comendo bola!

você coloca o CDATA na tag infCPL?

Não coloco não, o que eu enviei está assim:

<infAdic><infCpl>CTR: 1033</infCpl></infAdic>

Até+!

Referente a ordem dos elementos, isso foi só balela pra enrolar o amigo aí, o próprio emissor deles faz na ordem que eles dizem estar errada…(a inversão é feita após a assinatura do XML)
Até!!!

Pessoal, boa tarde.

É com imenso prazer que passo as dicas de como resolver o problema do erro 588.

Realizem os passos:

1. Dexem o cabeçalho do arquivo XML da seguinte forma:

Esta alteração poderá ser feita também para os ambientes de produção porque não dará o erro.

Abraço e boa sorte a todos.

O meu XML sempre foi gerado como sendo uma única linha (mesmo depois de assinado) e nunca me retornou esse erro.

Tudo na versão 2.0

<?xml version="1.0" encoding="UTF-8"?><enviNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="2.00"><idLote>000018</idLote><NFe><infNFe Id="NFe35100902767116000186550010000266501011246535" versao="2.00"><ide><cUF>35</cUF><cNF>01124653</cNF><natOp>RET P/ BENEFICIAMENTO</natOp><indPag>0</indPag><mod>55</mod><serie>1</serie><nNF>26650</nNF><dEmi>2010-09-01</dEmi><dSaiEnt>2010-09-01</dSaiEnt><hSaiEnt>12:46:52</hSaiEnt><tpNF>1</tpNF><cMunFG>3550308</cMunFG><tpImp>1</tpImp><tpEmis>1</tpEmis><cDV>5</cDV><tpAmb>2</tpAmb><finNFe>1</finNFe><procEmi>0</procEmi><verProc>1.0</verProc></ide><emit><CNPJ>02767116000186</CNPJ><xNome>LAMIPRINT ACABAMENTOS GRAFICOS LTDA. EPP</xNome><xFant>LAMIPRINT</xFant><enderEmit><xLgr>RUA ANDRE DE LEAO</xLgr><nro>55</nro><xBairro>MOOCA</xBairro><cMun>3550308</cMun><xMun>SAO PAULO</xMun><UF>SP</UF><CEP>03054010</CEP><cPais>1058</cPais><xPais>BRASIL</xPais><fone>[telefone removido]</fone></enderEmit><IE>115517636116</IE><CRT>3</CRT></emit><dest><CNPJ>06342420000132</CNPJ><xNome>ARVATO DO BRASIL IND E SERV GRAF LOG E DISTR LTDA</xNome><enderDest><xLgr>RUA DR. EDGARD TEOTONIO SANTANA</xLgr><nro>387</nro><xBairro>BARRA FUNDA</xBairro><cMun>3550308</cMun><xMun>SAO PAULO</xMun><UF>SP</UF><CEP>01140030</CEP><cPais>1058</cPais><xPais>BRASIL</xPais><fone>33834500</fone></enderDest><IE>ISENTO</IE><email>[email removido],</email></dest><det nItem="1"><prod><cProd>32113</cProd><cEAN/><xProd>LAMINACAO BRILHO FRENTE - OS: 19997</xProd><NCM>37031029</NCM><CFOP>5124</CFOP><uCom>FL</uCom><qCom>3350.0000</qCom><vUnCom>0.3113</vUnCom><vProd>1043.00</vProd><cEANTrib/><uTrib>FL</uTrib><qTrib>3350.0000</qTrib><vUnTrib>0.3113</vUnTrib><indTot>1</indTot></prod><imposto><ICMS><ICMS00><orig>0</orig><CST>00</CST><modBC>0</modBC><vBC>1043.00</vBC><pICMS>18.00</pICMS><vICMS>187.74</vICMS></ICMS00></ICMS><PIS><PISAliq><CST>01</CST><vBC>1043.00</vBC><pPIS>3.00</pPIS><vPIS>31.29</vPIS></PISAliq></PIS><COFINS><COFINSAliq><CST>01</CST><vBC>1043.00</vBC><pCOFINS>0.65</pCOFINS><vCOFINS>6.78</vCOFINS></COFINSAliq></COFINS></imposto><infAdProd>TESTE PARA O PRODUTO: LAMINACAO BRILHO FRENTE - OS: 19997</infAdProd></det><det nItem="2"><prod><cProd>32189</cProd><cEAN/><xProd>LAMINACAO BRILHO FRENTE - OS: 19997</xProd><NCM>37031029</NCM><CFOP>5124</CFOP><uCom>FL</uCom><qCom>2350.0000</qCom><vUnCom>0.3115</vUnCom><vProd>732.00</vProd><cEANTrib/><uTrib>FL</uTrib><qTrib>2350.0000</qTrib><vUnTrib>0.3115</vUnTrib><indTot>1</indTot></prod><imposto><ICMS><ICMS00><orig>0</orig><CST>00</CST><modBC>0</modBC><vBC>732.00</vBC><pICMS>18.00</pICMS><vICMS>131.76</vICMS></ICMS00></ICMS><PIS><PISAliq><CST>01</CST><vBC>732.00</vBC><pPIS>3.00</pPIS><vPIS>21.96</vPIS></PISAliq></PIS><COFINS><COFINSAliq><CST>01</CST><vBC>732.00</vBC><pCOFINS>0.65</pCOFINS><vCOFINS>4.76</vCOFINS></COFINSAliq></COFINS></imposto><infAdProd>TESTE PARA O PRODUTO: LAMINACAO BRILHO FRENTE - OS: 19997</infAdProd></det><total><ICMSTot><vBC>1775.00</vBC><vICMS>319.50</vICMS><vBCST>0.00</vBCST><vST>0.00</vST><vProd>1775.00</vProd><vFrete>0.00</vFrete><vSeg>0.00</vSeg><vDesc>0.00</vDesc><vII>0.00</vII><vIPI>0.00</vIPI><vPIS>53.25</vPIS><vCOFINS>11.54</vCOFINS><vOutro>0.00</vOutro><vNF>1775.00</vNF></ICMSTot></total><transp><modFrete>0</modFrete></transp><cobr><fat><nFat>026650</nFat><vOrig>1775.00</vOrig><vLiq>1775.00</vLiq></fat><dup><nDup>026650-</nDup><dVenc>2010-10-06</dVenc><vDup>1775.00</vDup></dup></cobr><infAdic><infCpl>RETORNO REFERENTE A MERCADORIA ENTREGUE ACOMPANHADA PELA NOTA FISCAL 26570 DIA 27/08</infCpl></infAdic></infNFe><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#NFe35100902767116000186550010000266501011246535"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>E2K6B7X0UOKO1HVMDx8JtOwQgqk=</DigestValue></Reference></SignedInfo><SignatureValue>CRprDAB+hEvozBgPolrPi+6NDoFjpjwUQw3Vk/ftQDEmTZcaiaDlFOC/aJsddib+M/kiddpMCeGz o9a1SDNzj5fLIMOLHlwAXcH7/8lK1veUCAeAs0o4g+L1o0PTDvVvoh02KNmKtUJ12pLEg3aDYvZw weDrGSRlPz6knpPaHsQ=</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIGyDCCBbCgAwIBAgIQaEQiU2uSuWTc/Va5Fa/JmTANBgkqhkiG9w0BAQUFADB0MQswCQYDVQQG EwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEtMCsGA1UECxMkQ2VydGlzaWduIENlcnRpZmljYWRv cmEgRGlnaXRhbCBTLkEuMSEwHwYDVQQDExhBQyBDZXJ0aXNpZ24gTXVsdGlwbGEgRzMwHhcNMTAw OTEzMDAwMDAwWhcNMTMwOTExMjM1OTU5WjCCAQ0xCzAJBgNVBAYTAkJSMRMwEQYDVQQKFApJQ1At QnJhc2lsMRUwEwYDVQQLFAxJRCAtIDExNTA2MDExKTAnBgNVBAsUIEF1dGVudGljYWRvIHBvciBB UiBGZWNvbWVyY2lvIFNQMRswGQYDVQQLFBJBc3NpbmF0dXJhIFRpcG8gQTMxFDASBgNVBAsUCyhF TSBCUkFOQ08pMRQwEgYDVQQLFAsoRU0gQlJBTkNPKTEwMC4GA1UEAxMnTEFNSVBSSU5UIEFDQUJB TUVOVE9TIEdSQUZJQ09TIExUREEgRVBQMSwwKgYJKoZIhvcNAQkBFh13YWduZXIubGFtaXByaW50 QHRlcnJhLmNvbS5icjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnj5bVJrzIqbz6POmAv12 WEB9R7P4w+tQfIcEqR6fexMc8awn++/iW6aYubOR8Y/frV+3KJ98nbZeRtmO56gtTFNcfFHxOIm/ rbZdTpzkpQEJZGl40fx+ArBsPEk3CEyUOcQREfS41ltH6qgjcSGcBawpCBCXNzCfqldum2tU21UC AwEAAaOCAz0wggM5MIG4BgNVHREEgbAwga2gPQYFYEwBAwSgNAQyMzAwMzE5NzAwOTQwODQxNjgx MzAwMDAwMDAwMDAwMDAwMDAwMDE4MjUzOTU2U1NQU1CgGQYFYEwBAwKgEAQOV0FHTkVSIEJFTExV Q0mgGQYFYEwBAwOgEAQOMDI3NjcxMTYwMDAxODagFwYFYEwBAwegDgQMMDAwMDAwMDAwMDAwgR13 YWduZXIubGFtaXByaW50QHRlcnJhLmNvbS5icjAJBgNVHRMEAjAAMB8GA1UdIwQYMBaAFISwQjM0 o0IlpSiXPoPrd/DoT8JUMA4GA1UdDwEB/wQEAwIF4DCCASUGA1UdHwSCARwwggEYMFygWqBYhlZo dHRwOi8vaWNwLWJyYXNpbC5jZXJ0aXNpZ24uY29tLmJyL3JlcG9zaXRvcmlvL2xjci9BQ0NlcnRp c2lnbk11bHRpcGxhRzMvTGF0ZXN0Q1JMLmNybDBboFmgV4ZVaHR0cDovL2ljcC1icmFzaWwub3V0 cmFsY3IuY29tLmJyL3JlcG9zaXRvcmlvL2xjci9BQ0NlcnRpc2lnbk11bHRpcGxhRzMvTGF0ZXN0 Q1JMLmNybDBboFmgV4ZVaHR0cDovL3JlcG9zaXRvcmlvLmljcGJyYXNpbC5nb3YuYnIvbGNyL0Nl cnRpc2lnbi9BQ0NlcnRpc2lnbk11bHRpcGxhRzMvTGF0ZXN0Q1JMLmNybDBVBgNVHSAETjBMMEoG BmBMAQIDBTBAMD4GCCsGAQUFBwIBFjJodHRwOi8vaWNwLWJyYXNpbC5jZXJ0aXNpZ24uY29tLmJy L3JlcG9zaXRvcmlvL2RwYzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwgaAGCCsGAQUF BwEBBIGTMIGQMCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcC5jZXJ0aXNpZ24uY29tLmJyMGQGCCsG AQUFBzAChlhodHRwOi8vaWNwLWJyYXNpbC5jZXJ0aXNpZ24uY29tLmJyL3JlcG9zaXRvcmlvL2Nl cnRpZmljYWRvcy9BQ19DZXJ0aXNpZ25fTXVsdGlwbGFfRzMucDdjMA0GCSqGSIb3DQEBBQUAA4IB AQA9VSlws6m3K+kO69X5d/GTKSjULwveaRN0Yz8tb5dI0kOGooO/ND4ltmMyUZLv6YXfU3BBVRVb NYd6iC0PUJe0DR4LlL99UOiPJtI/Y+9kCRmHjrZZfvn1qe1GMVhP1FhXY1xGqOscr/m7A9urbxr1 FpgSWVCeN61METKuUCk/pW5uc6FsRYzET1yB7TB1lLNRE83Z4S4fhXnDA+Mq9rrPvnsV1kUrA/GL MBLTfEf0K+doAnwf2aqcwBoLlN1BoJFHRgJtwv2x4j9254bePxRfxxXMseUp6j1zWHtFRUK2Z2RS JL0DuRvtAOOuVT5TCqSFC5sfU/xAqvOZ9DpWbW9y</X509Certificate></X509Data></KeyInfo></Signature></NFe></enviNFe>

Você remove \n e \r inclusive da assinatura?
Quando meu assinador assina o XML ele coloca varias quebras de linha!
Uma vez fiz um teste removendo e ele invalidou a assinatura!

A/C Fórum,

Legal pessoal, graças a ajuda de vocês também consegui fazer voltar a funcionar, foi só tirar as quebras de linhas que eu estava colocando entre as tags do XML.


Obrigado,
Dankshit

Na assinatura não mexo.
Gero o arquivo XML e ai chamo um objeto que assina e já envia diretamente.
Vale lembrar a todos que o problema do SEFAZ está só no ambiente de hmologação da versão 2.00, no ambiente de produção está perfeito.
Eu tenho por volta de 4000 pontos de emissão dos meus clientes que já estão na versão 2.00 e não estão com esse problema, porém se colocarem para enviar para homologação dá o erro.
Abraços.

Engraçado, o meu também sempre foi gerado em uma única linha e ainda continua dando erro!
abri o XML no notepad++
mandei mostrar os caracteres de quebra de linha e não tem nenhum
só tem quebra na assinatura como o exemplo ai em cima!

Continuo com problema, vou continuar olhando aqui!

Galera consegui resolver o problema tirando todos espaços que estão entre os “>” e “<”.
Não sei pq meu componente ao assinar gera esses campos com esses espaços :?

ex:
…0c5rHR+l6ghprBRNIvc0nO68v0E= MIIGST…30FUf1EFdkQ=

Alterando para:
…0c5rHR+l6ghprBRNIvc0nO68v0E= MIIGST…30FUf1EFdkQ=

Espero ter ajudado.

…

Pessoal,

Acabei de fazer um teste. Retirei todos os caracteres de formatação (enter, tab e espaco entre as tags) do xml enviado para a sefaz SP no ambiente de homologacao ( que já está com o pacote da NT 2010.007) e funcionou.
Conclusao: para funcionar somente se mudarmos o xml que está sendo enviado, passando a enviar um linguição!
Porém as tags de assinatura são formatadas automaticamente com quebras de linha.
Abri um chamado na sefaz. Assim que tiver um retorno eu escrevo denovo.

Andreza

Caramba!! Diego escrevemos juntos.

O problema é ficar alterando tags apos a assinatura… não acho que seja o modo mais elegante de se resolver!!

AND

de fato, é preciso identificar a causa do problema, pois alterar a tag seria meio que uma gambiarra

Realmente elegante não é, mas como o governo não ajuda, não tive outra opção pois tenho pressa.
Apenas tentei ajudar, e assim que alguém mais capacitado conseguir uma maneira mais elegante e que compartilhe com a gente, vou ficar muito feliz.

Grato

Você tem razão. Esses dias tivemos um trabalhao pra atendender a sefaz do MS que nao aceitava a chamada do servico com o atributo MustUndestand… Osso! Todas as outras aceitam… e para ela tivemos que rebolar!
Ai céus!

Só pra complementar aqui minhas investigações, mandei msg pra sefaz SP
aqui eu removi todos os caracteres e não resolve o problema como com vocês, eu não removi na assinatura pois acredito ser errado.

Haviam dito que a resposta do lote estava com uma versão nova do scheema:

<retEnviNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="2.00"><tpAmb>2</tpAmb><verAplic>SP_NFE_PL_006h</verAplic><cStat>103</cStat><xMotivo>Lote recebido com sucesso</xMotivo><cUF>35</cUF><dhRecbto>2010-10-06T09:34:10</dhRecbto><infRec><nRec>351000022388602</nRec><tMed>1</tMed></infRec></retEnviNFe>

essa versão do aplicativo SP_NFE_PL_006h já era a mesma quando minhas notas voltavam com sucesso, não atualizaram nada ao que parece mesmo.
Só não consigo entender por que de uma hora pra outra todo mundo começou a passar pelo mesmo problema.
Estou esperando resposta do SEFAZ
alguém alem de mim ainda continua com o problema?

Só pra complementar aqui minhas investigações, mandei msg pra sefaz SP
aqui eu removi todos os caracteres e não resolve o problema como com vocês, eu não removi na assinatura pois acredito ser errado.

Haviam dito que a resposta do lote estava com uma versão nova do scheema:

<retEnviNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="2.00"><tpAmb>2</tpAmb><verAplic>SP_NFE_PL_006h</verAplic><cStat>103</cStat><xMotivo>Lote recebido com sucesso</xMotivo><cUF>35</cUF><dhRecbto>2010-10-06T09:34:10</dhRecbto><infRec><nRec>351000022388602</nRec><tMed>1</tMed></infRec></retEnviNFe>

essa versão do aplicativo SP_NFE_PL_006h já era a mesma quando minhas notas voltavam com sucesso, não atualizaram nada ao que parece mesmo.
Só não consigo entender por que de uma hora pra outra todo mundo começou a passar pelo mesmo problema.
Estou esperando resposta do SEFAZ
alguém alem de mim ainda continua com o problema?

Rafael Rossignol, tem como vc fazer apenas uma nfe tirando os espaços em branco entre as tags de assinatura?
é que eu gostaria de saber se esse é realmente um dos problemas, para que eu possa assim argumentar melhor com o pessoal do governo.
Pois se for isso, a mensagem de erro deles está errada, pois espaços não são caracteres de edição. :?

Grato

Todos os meus XML não contém espaços entre tags, de nenhum tipo, nem da nota nem da assinatura, existe espaço em campos descritivos como o de municipio e quebras de linha no meio da assinatura, pois acredito que faz parte da própria assinatura.

E acredito que já foram uns 5000 xml para a homologação desde o começo do problema (aqui fizemos um esquema hibrido que manda nota pra produção e homologação ao mesmo tempo)
todos eles são rejeitados com o mesmo problema.

A propósito, o que são “caracteres de edição”?
ah e o erro 588 não está catalogado no manual, assim fica fácil acreditar neles (isso foi sarcasmo)

Acho que descobri o problema, porém ainda preciso descobrir como vou testar isso, seguinte:
abri 2 xml no notepad++ e mandei mostrar os caracteres estranhos (fiz isso desde o começo do problema, só que só percebi agora)
um xml foi eu que assinei com meu software
o outro foi o software da sefaz SP

percebi que as quebras de linha que estão dentro das tags <X509Certificate> e <SignatureValue> possuem CR e LF isso quando assinadas pelo meu assinador (Que peguei o código aqui no guj)
quando passa pelo assinador da SEFAZ as quebras de linha só contém LF
deve ser isso.

Agora a questão é: como vou fazer para meu assinador assinar sem colocar o maldito CR ali?

vixi… agora complicou

Eu tinha lido que caracteres de edição eram os caracteres de uso do xml (Ex: <, >, ", /, =, etc)
mas agora estava lendo e parece que caracteres de edição são os caracteres os usados para dar uma melhor visualização de uma informação (Ex: máscaras).
Acho que posso ter me precipitado ao dizer que espaço não é um caractere de edição. :?

Como que eles não colocam esse erro no manual??! Eles são uns fdp mémo viu!! :evil:
Não acredito que eles não leram nenhuma reclamação sobre este erro!! deve ser preguiça ou desleixo deles!!

Rafael Rossignol:

Engraçado, o meu também sempre foi gerado em uma única linha e ainda continua dando erro!
abri o XML no notepad++
mandei mostrar os caracteres de quebra de linha e não tem nenhum
só tem quebra na assinatura como o exemplo ai em cima!

Continuo com problema, vou continuar olhando aqui!

Bom dia,

Aqui na empresa estamos com o mesmo problema em homologacao de SP, emitimos notas para BA e ES tb e nao temos o mesmo problema.
Acredito que o problema esta mesmo nos caracteres CR LF que sao adicionados no momento da assinatura.
Se alguem tiver uma luz de como daria no momento da assinatura nao colocar esse caracteres sera muito bem vinda.
To escrevendo um codigo pra remover esses caracteres depois, mas nao sei se seria a forma correta de resolver isso.

Obrigado.

Eu fiz um replaceAll("\r","") no final do meu assinador e mesmo assim não resolveu
Estou investigando mais algumas coisas, assim que tiver novidades eu aviso!

Segue um dos meus linguições, ops, XML:

http://twitpic.com/2xrqpb/full
(editei aqui, pq o xml aqui tava fazendo travar o post)

A propósito, achei que tinha a ver com encoding e coisas assim, forcei UTF-8 de todas as maneiras que consegui, e fiz replace de CR (\r) por nada ("") e não resolveu.
O problema é que após eu guardar o xml no BD ele coloca os marditos CR de novo, já pensei q podia ser isso mas não é, pois eu assino e envio o XML tudo em memória antes de armazenar no BD.

Então, assinei a nota com meu software e transmiti sem problemas pelo software da SEFAZ.
To achando que pode ser na hora que envio ou na hora que gero o lote.

Alguém pode me dizer como faz a transmissão?
Eu utilizei o apache axis2 e mandei gerar o cliente pelo eclipse, ele gera duas classes (pra cada webservice, segue exemplo)
NfeRecepcao2Stub e
NfeRecepcao2CallbackHandler

OMElement ome = AXIOMUtil.stringToOM(xmlLote);
        NfeRecepcao2Stub.NfeDadosMsg dadosMsg = new NfeRecepcao2Stub.NfeDadosMsg();
        dadosMsg.setExtraElement(ome);

        NfeRecepcao2Stub.NfeCabecMsg nfeCabecMsg = new NfeRecepcao2Stub.NfeCabecMsg();
        nfeCabecMsg.setCUF(uf.toString());
        nfeCabecMsg.setVersaoDados(VERSAO);
        NfeRecepcao2Stub.NfeCabecMsgE nfeCabecMsgE = new NfeRecepcao2Stub.NfeCabecMsgE();
        nfeCabecMsgE.setNfeCabecMsg(nfeCabecMsg);

        NfeRecepcao2Stub stub = new NfeRecepcao2Stub();

        NfeRecepcao2Stub.NfeRecepcaoLote2Result result = stub
                .nfeRecepcaoLote2(dadosMsg, nfeCabecMsgE);
        return result.getExtraElement().toString();

To achando que o tal do cabeçalho ele manda com as tais quebras de linha.
Alguém faz diferente disso pra transmitir?
se faz, tem como mandar um exemplo?

Obrigado de antemão.

Alguém ainda está com esse problema ou sou só eu?

Rafael Rossignol:

Então, assinei a nota com meu software e transmiti sem problemas pelo software da SEFAZ. To achando que pode ser na hora que envio ou na hora que gero o lote.

Alguém pode me dizer como faz a transmissão?
Eu utilizei o apache axis2 e mandei gerar o cliente pelo eclipse, ele gera duas classes (pra cada webservice, segue exemplo)
NfeRecepcao2Stub e
NfeRecepcao2CallbackHandler

para transmitir

OMElement ome = AXIOMUtil.stringToOM(xmlLote);
        NfeRecepcao2Stub.NfeDadosMsg dadosMsg = new NfeRecepcao2Stub.NfeDadosMsg();
        dadosMsg.setExtraElement(ome);

        NfeRecepcao2Stub.NfeCabecMsg nfeCabecMsg = new NfeRecepcao2Stub.NfeCabecMsg();
        nfeCabecMsg.setCUF(uf.toString());
        nfeCabecMsg.setVersaoDados(VERSAO);
        NfeRecepcao2Stub.NfeCabecMsgE nfeCabecMsgE = new NfeRecepcao2Stub.NfeCabecMsgE();
        nfeCabecMsgE.setNfeCabecMsg(nfeCabecMsg);

        NfeRecepcao2Stub stub = new NfeRecepcao2Stub();

        NfeRecepcao2Stub.NfeRecepcaoLote2Result result = stub
                .nfeRecepcaoLote2(dadosMsg, nfeCabecMsgE);
        return result.getExtraElement().toString();

To achando que o tal do cabeçalho ele manda com as tais quebras de linha.
Alguém faz diferente disso pra transmitir?
se faz, tem como mandar um exemplo?

Obrigado de antemão.

public TRetEnviNFe enviarNotaFiscal(String arquivoXML, String cUF) throws AxisFault, RemoteException, ParserConfigurationException, SAXException, IOException, JAXBException, KeyStoreException, NoSuchAlgorithmException, CertificateException {
    if (!Global.PROPRIEDADES_CERTIFICADO_OK) {
        setPropriedadesCertificado();
    }
    emissor.ws.h.recepcaonota.NfeRecepcao2Stub.NfeCabecMsg cabecalho = new emissor.ws.h.recepcaonota.NfeRecepcao2Stub.NfeCabecMsg();
    cabecalho.setCUF(cUF);
    cabecalho.setVersaoDados(NFe.VERSAO_LEIAUTE_NFE);

    emissor.ws.h.recepcaonota.NfeRecepcao2Stub.NfeCabecMsgE cabE = new emissor.ws.h.recepcaonota.NfeRecepcao2Stub.NfeCabecMsgE();
    cabE.setNfeCabecMsg(cabecalho);

    String nfeDadosMsg = getXmlFromFile(arquivoXML);

    OMElement el = null;
    try {
        el = AXIOMUtil.stringToOM(nfeDadosMsg);
    } catch (XMLStreamException e1) {
        e1.printStackTrace();
    }
    el.build();

    NfeRecepcao2Stub.NfeDadosMsg dadosMsg = new NfeRecepcao2Stub.NfeDadosMsg();
    dadosMsg.setExtraElement(el);

    String urlRecepcaoNota = (String) mapUrlServicos.get(Global.TIPO_AMBIENTE_NFe).get(this.KEY_URL_RECEPCAO_NOTA);
    NfeRecepcao2Stub stub = new NfeRecepcao2Stub(urlRecepcaoNota);

    NfeRecepcao2Stub.NfeRecepcaoLote2Result result = null;
    result = stub.nfeRecepcaoLote2(dadosMsg, cabE);

    String strXmlRetorno = result.getExtraElement().toString();
    //System.out.println("XML recepcao: " + strXmlRetorno);
    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
    factory.setNamespaceAware(true);
    Document doc = factory.newDocumentBuilder().parse(new ByteArrayInputStream(strXmlRetorno.trim().getBytes("UTF8")));
    Element root = doc.getDocumentElement();

    // Para colocar o xml de retorno no objeto RTetEnviNFe
    JAXBContext context = JAXBContext.newInstance("emissor.bean.nfe.consret");
    Unmarshaller unmarshaller = context.createUnmarshaller();

    TRetEnviNFe retorno = unmarshaller.unmarshal(root, TRetEnviNFe.class).getValue();
    return retorno;
}

Agora nem eu.
Meu problema era que na hora de consultar o recibo eu estava mandando quebra de linha, o idiota aqui conferiu tudo em relação ao xml da nota em si, mas não mexi no xml para envio do recibo.

Uma duvida galera

qdo fiz os webservices da versão 2.0 , para montar o xml de requisão tanto para serviço, consulta, consultaret, transmissão

é ou era necessario incluir a tag no inicio e no fim de todo o conteudo para poder funcionar

no caso da trasmissão que na mensagem de requisição colocamos a Nota , ex:

<?xml version="1.0" encoding="UTF-8"?><nfeDadosMsg><enviNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="2.00"> <idLote>201010438</idLote> <NFe> ................</enviNFe></nfeDadosMsg>

fiquei agora na duvida se é realmente valido colocar na mensagem , pois o erro 588 - deu a entender que tem algo a mais dentro da mensagem de requisição

só que tirando a tag da outros erros mais nebulosos , alguem sabe de algo do tipo ?

Galera seguinte

Fiz alguns teste e cheguei ao seguinte resultado sobre o erro 588

transmiti um nota seguindo o padrao que usava com a nota montada da seguinte maneira

XML - Nota

<?xml version="1.0" encoding="UTF-8"?><enviNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="2.00">
<idLote>201010438</idLote>
<NFe>
<infNFe Id="NFeXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" versao="2.00">
<ide>..............
</NFe>
</enviNFe>

e na transmissão era colocado a tag antes da tag

ao consultar essa nota retornava o erro 588

peguei a msm nota agora removendo as tag e mantendo apenas na transmissão a tag

e não ocorreu mais o erro 588

como está voltado ainda falha no esquema XML ainda preciso confirmar se nao tem outro tipo de erro no meu xml

mais façam esse teste para ver se funciona

Evandro, parou de dar o erro 588 pois vc causou um erro pior q o 588 que é uma falha de scheema
eu não acrescento a tag <nfeDadosMsg> no meu
quem adiciona essa tag é o cliente xml que eu gerei no eclipse, portanto isso depende do metodo de envio do XML ao webservice.
O erro 588 ocorre por que tem quebra de linha no XML e espaço entre as tags
e isso não ocorre só no XML que contém a nota
eu estava com problema pois o XML que eu envio para o webservice RetRecepção (aquele xml que contem o numero do recibo) tinha esses problemas também (quebra de linha e tabs).

Rafael

é realmente nao aparece o 588 pq gerei outro erro rs , mais meu xml nao contem spaço entre as tag e tanto com quebra de linha ou sem quebra de linha o erro 588 se mantem

Você fala de qual XML? você conferiu o que você enviou no serviço nfeRecepcao

depois pra ver o resultado vc manda outro xml no nfeRetRecepcao
esse outro xml a tag raiz é <consReciNFe>
verifique se esse contém quebra de linha e espaço ou tab entre as tags!
tem q ser um linguição, uma linha só.

entao verifiquei e está aparentimente ok

<nfeDadosMsg><consReciNFe versao="2.00" xmlns="http://www.portalfiscal.inf.br/nfe"><tpAmb>2</tpAmb><nRec>351000023126416</nRec></consReciNFe></nfeDadosMsg>

sem quebra de linha e sem espaço

não tive esse problema aqui mas veja:
<consReciNFe versao=“2.00”

tem espaço duplo entre o atributo versao e a tag consReciNFe

tenta tirar isso!
ve se não tem espaço duplo em outros locais, eu arranquei todos!
>

tirei td q tinha de espaço a mais e continuou na msm

manda o seu xml para eu poder comparar , claro se for possivel

o xml de nota eu mandei alguns posts atras
esse dai eu nem armazeno eu gero e envio quando precisa

só pra lembrar a tag <nfeDadosMsg>
eu nunca enviei, o metodo de envio do xml eu mandei alguns posts atras também
eu gerei as classes usando axis2

entao tb sempre utilizei o axis2 e sempre funcionou dentro desses parametros

qdo eu tiro a tag

retorna java.lang.Exception: org.apache.axis2.databinding.ADBException: Unexpected subelement nRec

assinando pelo meu programa volta erro 588
se assino o xml com o programa do governo , volta erro de 225 - falha no schema de lote nfe

ta complicado a coisa rs

Bom, tenta manter então essa tag, segue algumas coisas q fiz aqui, tenta implementar e ve se resolve:

xmlNfe = xmlNfe.replaceAll("\n", "")
                .replaceAll("\r", "")
                .replaceAll("\t", "")
                .replaceAll("  ", " ")
                .replaceAll("  ", " ")
                .replaceAll("> <", "><")
                .replaceAll(" </", "></")
                .replaceAll("> ", ">")
                .trim();

ByteArrayOutputStream os = new ByteArrayOutputStream();
        TransformerFactory tf = TransformerFactory.newInstance();
        Transformer trans = tf.newTransformer();
        trans.setOutputProperty(OutputKeys.INDENT, "no");
        trans.setOutputProperty(OutputKeys.ENCODING, "UTF-8");
        trans.setOutputProperty(OutputKeys.MEDIA_TYPE, "text/xml");
        trans.setOutputProperty(OutputKeys.METHOD, "xml");
        trans.transform(new DOMSource(docs), new StreamResult(os));

return new String(os.toByteArray(),Charset.forName("UTF-8")).trim();

Valeu Rafael

fiz a remoção dos “\n” quebra de linha antes de assinar e consegui transmitir tranquilo e receber o protocolo de autorização sem erro

obrigado pela dicas se precisar estamos por aqui ( no aguardo de mais problemas rs )

Salve galera …

estava com este mesmo problema e percebi que ao enviar o lote, no final tinha uma quebra de linha antes da última tag para fechar o XML de envio de lote, no caso a tag (na versão antiga da NFe funfava, na 2.0 não).

daí pra resolver fiz o básico, retirei a quebra de linha do XML com um:

replaceAll("\n", “”)

mas … não funcionou … continuou o mesmo problema … quando eu visualizava o XML dentro do netbeans aparecia sem a quebra de linha, mas se eu “colava” o XML em um editor de texto a quebra de linha aparecia … (glub !!)

pois resolvi o problema substituindo a mesma linha do replace por esta sintaxe:

.replaceAll( System.getProperty(“line.separator”), “” )

daí funfou … ah, e as quebras de linhas geradas na assinatura do XML não interferiram em nada … este foi o meu problema quebra de linha e o replace que não funfou direito nao sei pq …

abs!!

André, existem quebras de linhas compostas por \r (CR ou carriage return) também
eu mandei um código logo acima q arranca "tudo essas m…" pra falar o bom português"

1. xmlNfe = xmlNfe.replaceAll("\n", "") 2. .replaceAll("\r", "") 3. .replaceAll("\t", "") 4. .replaceAll(" ", " ") 5. .replaceAll(" ", " ") 6. .replaceAll("> <", "><") 7. .replaceAll(" </", "></") 8. .replaceAll("> ", ">") 9. .trim();

Pessoal,

O meu arquivo eu gero normal e transmito com os \n da assinatura e autoriza normalmente.

O problema que eu tive com a Sefaz SP foi com um XML que eu estava enviando com a tag com espaços.

Ex:

<email>                       </email>

Porém resolvendo isso. Todas as notas foram autorizadas.

[]s

Boa tarde!

Estou enfrentando o mesmo problema.

Observando as especificações, foi publicada uma nota técnica (NT2010_009) que inclui a validação 588. Vide link: http://www.nfe.fazenda.gov.br/PORTAL/docs/NT2010.009.pdf. Neste mesmo documento está especificado que a princípio, esta validação seria feita apenas no ambiente de homologação.

Contudo, removi do xml enviado todas as formatações bem como os caracteres de edição informados na nota técnica e o problema persistiu.

Observei que a assinatura continha caracteres de retono de carro “\n” e também os removi do xml enviado. Porém a SEFAZ rejeitou a nota porque a assinatura difere da calculada - era de se esperar este resultado.

Já abri um chamado para a SEFAZ-GO (já que não tenho o endereço de e-mail dos responsáveis pelo SCAN) questionando sobre este problema, mas gostaria de saber se alguém já conseguiu solucionar este problema? poderiam dar um help?

Agradeço antecipadamente.

Att.

Bom, incrível como a comunidade java é desunida, aposto que muitos já conseguiram solucionar este problema , mas cada um que se vire né?!

Nem adianta falar que já postou que resolveu utilizando isso ou aquilo. Fazer somente isso e nada é a mesma coisa. Como diz Linus Torvalds: “show me the code”.

Pois eh galera, sobre este erro, o meu XML não continha os caracteres de edição conforme o SCAN validara (isso mesmo, essa rejeição só aparecia no ambiente de homologação do SCAN).

Como sempre, a SEFAZ não respondeu à minhas dúvidas e tive que me virar - novamente…

O problema de rejeição 588 só acontecia porque o algorítimo e componentes que utilizava para assinar (ou assassinar[i], como preferir…) o XML gerava a assinatura com caracteres de quebra de linha entre as tags internasdo elemento <signature>. Os valores das tags de assinatura podem ter quebras de linha ("\n") normalmente, mas entre as tags JAMAIS isso deve acontecer.

Enfim, utilizava a api Apache org.apache.xml.security para assinar (com o erro) e substitui o código pelos componentes do próprio java (javax.xml.crypto.dsig) e a coisa funfou…

No meu caso eu utilizo o HSM para manter o certificado mas depois de obtido, não muda em nada para quem adota outros modelos de certificados.

Final Code:

//Assina o xml da nota....o parâmetro xml contém todo o arquivo xml <NFe>...</NFe> preenchido
//O parâmetro tagname contém o nome da tag infNFe e o parâmetro nome possui o cnpj do emitente para que seja possível
//encontrar o certificado do cnpj no cache....
// O restante é bem legível
private static String signX(String xml, String tagname, String nome) throws Exception {

			//Converte a string do xml em um objeto Document
			Document document = DOMUtils.stringToDocument(xml);
			
			Key key = KeyStoreBuilder.get(nome).getKey();
			
			X509Certificate x509Certificate = getCertificadoDoBuffer(nome);
			
			XMLSignatureFactory sf = XMLSignatureFactory.getInstance("DOM");
			
			List<Transform> lt = new ArrayList<Transform>();

			Node infNFe = document.getElementsByTagName(tagname).item(0);
			
			((Element)infNFe).setIdAttribute("Id", true);
			
			String id = "#"+infNFe.getAttributes().getNamedItem("Id").getNodeValue();
			
			lt.add(sf.newTransform("http://www.w3.org/2000/09/xmldsig#enveloped-signature", (TransformParameterSpec) null));
			lt.add(sf.newTransform("http://www.w3.org/TR/2001/REC-xml-c14n-20010315", (TransformParameterSpec) null));
			
			Reference ref = sf.newReference(id, sf.newDigestMethod("http://www.w3.org/2000/09/xmldsig#sha1", null), lt, null, null);
			SignedInfo si = sf.newSignedInfo(sf.newCanonicalizationMethod("http://www.w3.org/TR/2001/REC-xml-c14n-20010315", (C14NMethodParameterSpec) null), sf.newSignatureMethod("http://www.w3.org/2000/09/xmldsig#rsa-sha1", null), Collections.singletonList(ref));
			
			KeyInfoFactory kif = sf.getKeyInfoFactory();
			
			X509Data data = kif.newX509Data(Collections.singletonList(x509Certificate));
			KeyInfo ki = kif.newKeyInfo(Collections.singletonList(data));
			
			DOMSignContext sc = new DOMSignContext(key, document.getDocumentElement());
			javax.xml.crypto.dsig.XMLSignature signature = sf.newXMLSignature(si, ki); 
			
			signature.sign(sc);
			//Obtem somente o conteúdo da tag <signature> da estrutura Documento - neste ponto ela já foi gerada.
			//Converte o conteúdo da assinatura <signature> em string e devolve apenas a string da assinatura para o cliente - esta é a minha necessidade, pode não ser a sua!
			return DOMUtils.nodeToString(document.getDocumentElement().getElementsByTagName("Signature").item(0));
			
		}

Espero ter ajudado. Vou almoçar!!

bye!

A pergunta é meio antiga, mas é melhor responder mesmo assim.
Eu resolvi o problema removendo a identação do xml, conforme o exemplo abaixo:

Antes tava assim e dava erro:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:nfes="http://www.portalfiscal.inf.br/nfe/wsdl/NfeStatusServico2"> <soap:Header> <nfes:nfeCabecMsg> <nfes:versaoDados>2.00</nfes:versaoDados> <nfes:cUF>41</nfes:cUF> </nfes:nfeCabecMsg> </soap:Header> <soap:Body> <nfes:nfeDadosMsg> <consStatServ versao="2.00" xmlns="http://www.portalfiscal.inf.br/nfe"> <tpAmb>2</tpAmb> <cUF>41</cUF> <xServ>STATUS</xServ> </consStatServ> </nfes:nfeDadosMsg> </soap:Body> </soap:Envelope>

Agora está assim e não dá mais erro:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:nfes="http://www.portalfiscal.inf.br/nfe/wsdl/NfeStatusServico2"><soap:Header><nfes:nfeCabecMsg><nfes:versaoDados>2.00</nfes:versaoDados><nfes:cUF>41</nfes:cUF></nfes:nfeCabecMsg></soap:Header><soap:Body><nfes:nfeDadosMsg><consStatServ versao="2.00" xmlns="http://www.portalfiscal.inf.br/nfe"><tpAmb>2</tpAmb><cUF>41</cUF><xServ>STATUS</xServ></consStatServ></nfes:nfeDadosMsg></soap:Body></soap:Envelope>

Mesmo que tardia fica a resposta para registro.