cancel
Showing results for 
Search instead for 
Did you mean: 

CTe Nota Técnica 2013.001 - Renavam com 11 dígitos

Former Member
0 Kudos

Boa tarde pessoal,

Vi que temos uma nota NT para CTe com alterações no schema do XML (Nota Técnica 2013.001).

Percebemos pois, nenhum CTe em ambiente de homologação hoje foi aprovado.

Estão todos com o erro: Rejeição: Falha no Schema XML específico para o modal [Det: The 'http://www.portalfiscal.inf.br/cte:RENAVAM' element is invalid - The value '123456789' is invalid according to its datatype 'String' - The actual length is not equal to the specified length

A nota menciona que houve uma alteração de 9 para 11 dígitos na tag RENAVAM.

Minha dúvida é: vocês sabem se do lado do GRC é necessário alguma alteração?

Pelo que vi, o xsd não tem a limitação do tamanho do campo.

É isso mesmo?

Procurei mas não vi nenhuma nota da SAP referente a este assunto, nem mesmo para o ECC.

Agradeço desde já.

Abraços,

Luciana R.

Accepted Solutions (1)

Accepted Solutions (1)

eduardohartmann
Contributor
0 Kudos

Luciana, boa tarde.

Saiu a nota Note 1847904 - CT-e: Technical Note 2013.001.

Summary

Symptom

CT-e: Technical Note 2013.001
RENAVAM is enlarged from 9 to 11 characters
VTOTIMP (total Tax Value) has been added to a number of structures

Other terms

Nota Técnica 2013/001, Conhecimento de Transporte Eletrônico, DACTE

Reason and Prerequisites

This SAP Note is only relevant for Brazil.
Prerequisites:
When SAP BusinessObjects Nota Fiscal Eletrônica (=GRC) is used as a messaging system then support package 14 must be installed.

Solution

As general rule, SAP recommends that you install a solution by applying  a Support Package. However, if you need to install a solution earlier, use the Note Assistant to implement the correction instruction. You can find more information about the Note Assistant in SAP Service Marketplace, under service.sap.com/note-assistant.

The purpose of VTOTIMP is not clear. As the field is optional, SAP leaves the field empty.

In the implementation of the technical note 2013/001 SEFAZ has added additional checks with regard to the completeness of the XML. For example the insurance information must be provided for road transports (see label SEG). SEFAZ will reject the CT-e returning codes 665 and 666 if the information is missing.

Abraço,

Eduardo Hartmann

Former Member
0 Kudos

Grande Eduardo.

Pelo que vi, as notas e as aplicações manuais, são no ECC e para o GRC, o pré requisito é o SP14 que nem está liberado ainda! =/

Será que é isso mesmo?

Muito obrigada pela informação!!

Abraços

Luciana R.

henrique_pinto
Active Contributor
0 Kudos

A dúvida é: o NFE vai forçar que um Renavam tenha 11 digitos quando ele tem 9 no cadastro?

Acredito que nao, e daí o erro vai continuar acontecendo, se a SEFAZ não corrigir o lado deles...

Former Member
0 Kudos

Então Henrique,

Quando tem 9, temos que mandar com zeros á esquerda.

Mas existem Renavans que estão sendo criados já com 11 posições... já são criados com 0 a esquerda.

henrique_pinto
Active Contributor
0 Kudos

Quando tem 9, temos que mandar com zeros á esquerda.

Nao deveria ter que, pois o layout XML do CTe aceita 9 digitos.

Isso é um workaround, como falei, pq a SEFAZ está fora do padrão.

Mas existem Renavans que estão sendo criados já com 11 posições... já são criados com 0 a esquerda.

Nesse caso nao há o que fazer, se o numero oficial tem 11 digitos, entao a SAP tem que de fato corrigir.

Mas e o cadastro do ERP está aceitando essa informacao com 11 digitos?

Former Member
0 Kudos

Oi Henrique,

Essa SAP Note que saiu hoje está contemplando esta alteração.

Ele menciona o seguinte passo manual:

Mas pelo que vi, o XSD no PI ainda considera somente 9 posições e não achei nenhuma nota aplicável ao GRC.

Aliás, a nota diz também:

*******************************************************************************************************

Reason and Prerequisites

This SAP Note is only relevant for Brazil.
Prerequisites:
When SAP BusinessObjects Nota Fiscal Eletrônica (=GRC) is used as a messaging system then support package 14 must be installed.

*******************************************************************************************************

Mas o SP14 ainda não está fechado e nem tem data definida para ser liberado.

E a obrigação começa em 15/05 (já falei isso 200 vezes nessa página...rs)

Abraços,

Luciana

henrique_pinto
Active Contributor
0 Kudos

Ah ok, essa nota era do ERP, entendi.

Anyway, como havia falado, no GRC eles tem q gerar um novo PI Content, entao acho dificil sair como nota, se o SP14 estiver planejado para antes de 15/05.

Voltando a questao do dado em si, é "correto" se forçar dois zeros a esquerda em um Renavam que tenha 9 digitos?? O Renavam "00123456789" e o "123456789" são considerados o mesmo pelo DETRAN??

former_member182114
Active Contributor
0 Kudos

Bom dia Pessoal,

O SP14 está previsto para 4 de junho.

Atenciosamente, Fernando Da Rós

henrique_pinto
Active Contributor
0 Kudos

créééu

Former Member
0 Kudos

é... para colocar o SP13 tem que ter o EHP5... agora + SP14. Deve ter um monte de gente sem dormir direito!

former_member182114
Active Contributor
0 Kudos

créééééééééééééu

Former Member
0 Kudos

Nossa!!!

Olha a SAP gerando empregos.. ahahah

Obrigada pessoal

Abraços

Luciana R.

henrique_pinto
Active Contributor
0 Kudos

Eduardo Chagas wrote:

é... para colocar o SP13 tem que ter o EHP5...

Só se tiver automação né, não é mandatório pro escopo do que estamos falando nessa thread...

Answers (4)

Answers (4)

Former Member
0 Kudos

No projeto atualmente o cliente tem SP12, trata-se de uma companiha global

e o cliente ira atualizar para o SP13 somente daqui 6 meses !!

Pergunto:

Seria possivel aplicarmos essa "alteracao"  do RENAVAM com uma determinada relacao de notas ?

Se a resposta for sim, Alguem poderia enviar por favor essa lista de notas que devem ser aplicadas ?

em caso de reposta negativa,

a unica solucao mesmo seria update para o SP13 e depois SP14 ou ate

configuracao manual (sabendo que podemos perder garantia do produto) certo ?

Obrigado

former_member182114
Active Contributor
0 Kudos

Bom dia Marcel,

Para o ERP sim tem já uma lista de notas (nesta thread tem ela comentada).

Para o SAP NFE deverá ir para o SP14 dada a dificuldade técnica de liberar mudanças nos objetos de proxy/XI por SAP Note.

Atenciosamente, Fernando Da Rós

henrique_pinto
Active Contributor
0 Kudos

No projeto atualmente o cliente tem SP12, trata-se de uma companiha global

e o cliente ira atualizar para o SP13 somente daqui 6 meses !!

Por que???

O SAP NFE é compartilhado com outros países também? =P

Former Member
0 Kudos

Algumas empresas trabalham com releases temporarios, ou seja so podem por exemplo

subir requests para producao de 3 em 3 meses ou de 6 em 6 meses,  o que infelizmente é o nosso caso   !!!!! por isso temos esse problema da espera....    !!

Valeu Henrique

henrique_pinto
Active Contributor
0 Kudos

Mas isso nao faz sentido pro SAP NFE.

Ter um processo padrão e aplicar pra toda e qualquer aplicação sem analisar se faz sentido é um crime.

O tempo que você perderia aplicando o SP13 no NFE é menor do que o que vc gastou pra criar um usuário no SCN, logar e fazer sua perguntar... E o impacto é mínimo e concentrado no cenário de negócio de NFe...

Former Member
0 Kudos

Entendo e concordo sobre o que voce falou sobre o impacto ser apenas no componente SLL-NFE.

Essas informacoes de prazo e impacto ja foram documentadas e passadas ao cliente.

Sobre a data para request em producao sao as regras da empresa, nao temos opcao !!

De qualquer forma agradeco atencao Henrique.

Former Member
0 Kudos

Pode parecer boba essa minha pergunta, mas por favor, essa validacao do RENAVAM,

sera feita apenas no CTe de saida ? ou serao feita tambem para os CTe de entrada ???

*No momento da entrada do Cte, validamos assinatura digital + Cte autorizado ou nao no SEFAZ,certo ??

nao haveria impacto para empresas que trabalham so com a validacao de entrada do CTe?

Muito obrigado.

former_member182114
Active Contributor
0 Kudos

Bom dia Marcel,

Afeta os emissores quanto a validação e poder enviar as 11 casas, e afeta o recebimento de CT-e com 11 casas não pela validação mas os objetos de proxy e schema rejeitarão um XML "mal formado" de 11 casas.

Devido a isso o pessoal tá "recebendo o XML" cortando dois dígitos para passar pelo proxy/validação de schema XML e depois no monitor dá OK para ignorar a verificação de assinatura pois foi assinado com 11 digitos, não 9.

Ou seja, quem emite e quem recebe são afetados.

Atenciosamente, Fernando Da Rós

Former Member
0 Kudos

Boa tarde Fernando, tudo bem?

Então, aplicamos a nota no ECC e agora o Renavam está com 11 dígitos no ERP.

Só que, quando o CTe cai no GRC, ele cai com 9 caracteres ainda, o que já era esperado.

O que não era esperado (pelo menos por mim), é que a SEFAZ iria aprovar os CTes.

No dia 15/04, quando a nota de CTe entrou em vigor, nenhum CTe foi aprovado em DEV e hoje, eles estão sendo aprovados mesmo estando com 9 dígitos.

Vocês sabem o que está acontecendo?

Abraços e obrigada,

Luciana R.

former_member182114
Active Contributor
0 Kudos

Bom dia Luciana,

Provavelmente corrigiram o sistema 🙂

A mudança do schema é para permitir também 11 dígitos, não que seja tudo 11 dígitos mas a alguns softwares de Sefaz não lêem o XML e sim o interpretam e aí podem interpretar errado.

O validador do SAP NFE (outgoing) também é uma interpretação do schema, visto que o time de desenvolvimento lê os schemas e decide por implementar via regra, via código, via transformação ou nem implementar (caso dos números onde só é necessário verificar se são negativos). E dar um grupo de mensagens um pouco mais próximo do negócio.

Já para entrada, ele segue o schema XSD.

Atenciosamente, Fernando Da Rós

Former Member
0 Kudos

Hummm.

Entendi!!!

Agora entendi que o Henrique comentou que o sistema da sefaz estava errado..rs

Eu havia entendido que, quando o renavam tivesse 9 dígitos, a partir de 15/04, teríamos que incluir zeros á esquerda para que ela validasse.

Agora ficou claro.

De qualquer maneira, o GRC está "comendo" 2 dígitos. No ECC temos 11 (em um teste que fizemos) e este Renavam chegou no GRC com apenas 9.

Deve ser por conta do XSD que ainda está limitando, certo?

Abraços e muito obrigada pelos esclarecimentos,

Luciana R.

former_member182114
Active Contributor
0 Kudos

Bom dia Luciana,

Exatamente isso que o Henrique pontuava.

O "comer" dois dígitos deve ser pela tamanho do campo na função /xnfe/nfe_create que deve estar como 9 dígitos. Isto também deve ser acertado no SP14 (domínio, validação, proxy, transformação)...

Atenciosamente, Fernando Da Rós

henrique_pinto
Active Contributor
0 Kudos

O que está acontecendo é que a SEFAZ resolveu se adequar ao Layout XML (XSD) standard definidos por eles mesmos!

henrique_pinto
Active Contributor
0 Kudos

Aee! Eu sabia que eu nao estava louco! Ainda... Rs...

Former Member
0 Kudos

Pessoal, outra dúvida sobre essa Nota Técnica.

Com relação ao serviço de Entrada, antes do dia 15/04 recebemos um CTe que possuia 11 digitos no RENAVAM e era rejeitado pelo validador do GRC com o seguinte faultText: "Error in XML transformation in tag cteProc(1)infCte(1)infCTeNorm(8)infModal(3)rodo(1)". Ao alterar o campo RENAVAM para 9 dígitos, a CTe foi processada sem erros.

Eu procurei por alguma SAP Note, mas não encontrei nada referente ao assunto. A minha dúvida é, como será feita a nova validação desse campo? Alguma SAP Note será lançada para atualizar o Validador de Entrada?

Muito obrigado!

Former Member
0 Kudos

Oi Alessandro,

Você alterou o valor do RENAVAM no XML?

Ficou com erro de validação de assinatura, certo ?

Pois é, o GRC ainda não está preparado para receber ou enviar CTes com RENAVAM com 11 dígitos e pelo visto, tem empresas que já aderiram ... rs

Abraços,

Luciana

henrique_pinto
Active Contributor
0 Kudos

Isso deverá ser tratado em algum SP futuro, pois envolve alteração de layout XML (PI Content) e código ABAP, portanto nao dá pra alterar só com nota...

A menos que lancem nota com passo manual para atualizacao do ExternalDefinition no PI.

Former Member
0 Kudos

Olá, Luciana!

Exatamente, foi alterado o valor do RENAVAM no XML e testamos sua entrada em ambiente DEV. Não houve problema no validador de entrada, mas no monitor ficou com erro de assinatura "The message digest from XML fragment is not equal to the calculated one".

Former Member
0 Kudos

Olá, Henrique!

E obrigado pela resposta! Existe alguma posição oficial da SAP em relação a essa mudança? Pois, de acordo com a Nota Técnica, essa mudança já está em vigor em Homologação e dia 15/05 estará também em Produção.

Abraços!

Former Member
0 Kudos

Então Henrique,

O problema é que isso será obrigatório em produção a partir de 15/05/2013 e está disponível para teste de de 15/04/2013 em homologação.

Nenhum CTe em homologação está sendo validado sem os 11 dígitos de Renavam.

Abrimos chamado na SAP mas até agora não tivemos respostas.

Abraços e obrigada

Former Member
0 Kudos

Alessandro,

Abrimos um chamado na SAP e responderam que está em desenvolvimento mas que ainda não tem nada definida.

Quando responderem eu posto aqui!

Espero que seja logo pois dia 15 teremos que ter isso em produção.. senão os ctes não serão aprovados ne?!

Abraços,

Luciana

Former Member
0 Kudos

Olá, Luciana!

Aqui também abrimos um chamado SAP, mas ainda não tivemos retorno. Muito obrigado por sua resposta, assim que eu tiver alguma novidade também posto aqui!

Abraço!

henrique_pinto
Active Contributor
0 Kudos

Ainda discordo que a SAP tenha que desenvolver alguma coisa aqui.

Isso é claramente um erro da SEFAZ, que não está implementando o que está definido no layout CTe standard! Se eles estivessem seguindo o layout, Renavam de 9 digitos seriam aceitos.

Vocês fizeram consulta oficial à SEFAZ em questão?

Qual a resposta?

henrique_pinto
Active Contributor
0 Kudos

São 2 coisas diferentes:

  1. Incapacidade do GRC de tratar CTes com Renavam de mais de 9 digitos: de fato é um problema que deve ser tratado pela SAP. Porém, para clientes que usam o SAP ERP, até onde entendi, o campo origem no cadastro aceita no máximo 9 digitos, então nem teria como gerar um CTe com Renavam de 11 digitos. Para clientes com ERPs nao-SAP, pode ser sim um problema mais crítico, se já houver algum transportador com Renavam de 11 digitos cadastrado.
  2. Incapacidade da SEFAZ de aceitar CTes com 9 digitos: isso é um erro da SEFAZ, pois não estão implementando o definido no layout CTe, que conforme colei acima, aceita Renavam de 9 a 11 digitos.

Alguém pode querer fazer um workaround para resolver o problema 2 forçando dois zeros à esquerda do Renavam via BAdI, e daí incorre no problema 1. Porém isso é um workaround, e não a solução da causa raiz. A SEFAZ tem que corrigir o sistema deles antes do prazo de 15/05, senão eles mesmos que não estão se adequando ao padrão ENCAT.

Cabe aqui uma consulta oficial à SEFAZ e também uma reclamação/consulta à coordenação do ENCAT responsável por NFe/CTe. Acredito que o melhor caminho para isso seria através da ASUG (Paulo Roberto) ou via GS1.

Former Member
0 Kudos

Povo,

Alguma luz ai?rsrs

Obrigada

pedro_baroni3
Active Contributor
0 Kudos

Oi Lu, tudo bem?

Pelo que vi no XSD da SEFAZ, este campo agora permite de 9 a 11 caracteres. Entretanto parece que a SEFAZ não ajustou seu WebService para tal, já que está rejeitando a informação de 9 caracteres no Renavam.

Abs.,

Pedro Baroni

Former Member
0 Kudos

Oi Pedro,

Obrigada pela ajuda.

Então, na verdade, a SEFAZ alterou o WS sim.

Antes permitiam 9 caracteres, agora 11.

Se você manda com 9, dá o erro que comentei lá em cima.

O pessoal ta esperando uma resposta da SAP quanto a alterações no ERP pois, lá, o campo limita a 9 caracteres numa tabela standard.

Acabei de ver o XSD govCteModalRodoviario de CTe do SP13, e o campo RENAVAM está com 9 caracteres.

Possivelmente a SAP terá atualizações do XSD também....:

<xs:element name="RENAVAM">

                                <xs:annotation>

                                    <xs:documentation>

                                    RENAVAM do veículo

                                    </xs:documentation>

                                </xs:annotation>

                                <xs:simpleType>

                                    <xs:restriction base="TString">

                                        <xs:length value="9" />

                                    </xs:restriction>

                                </xs:simpleType>

                            </xs:element>

Abraços e obrigada

henrique_pinto
Active Contributor
0 Kudos

Mas o XSD standard do CTe permite de 9 a 11.

Apesar de o PDF da Nota Técnica falar apenas em 11.

<xs:element name="RENAVAM">

     <xs:annotation>

          <xs:documentation>RENAVAM do veículo </xs:documentation>

     </xs:annotation>

     <xs:simpleType>

          <xs:restriction base="TString">

               <xs:minLength value="9"/>

               <xs:maxLength value="11"/>

          </xs:restriction>

     </xs:simpleType>

</xs:element>

A SEFAZ que não está implementando o WS de acordo com a definição do XSD...

Tem q abrir chamado com eles e esperar uma definição.