CT-e Globalizado não pode ser utilizado

[Elviro]

Bom dia pessoal, fui enviar meu CT-e e apareceu essa mensagem " Rejeição: CT-e Globalizado não pode ser utilizado para operação interestadual"

Alguém sabe como resolver?

[Juliomar Marchetti]

boa tarde

veja se não preencheu algo relacionado ao globalizado

http://portalcte.fazenda.mg.gov.br/download/SP01_CT-e_Globalizado_v2.pdf

[Elviro]

29 minutos atrás, Juliomar Marchetti disse:

boa tarde

veja se não preencheu algo relacionado ao globalizado

http://portalcte.fazenda.mg.gov.br/download/SP01_CT-e_Globalizado_v2.pdf

Foi isso mesmo amigo, fiz a correção e deu certo!

[wellida de cassia]

A UF de início e UF fim devem ser a mesma, não poderá ter UF início GO e UF fim BA.

[Luciano Alberti]

Estou fazendo testes com o CTE 3.00 e me aparece essa mensagem "Rejeição: CT-e Globalizado não pode ser utilizado para operação interestadual". Vi a documentação do link acima e não consegui entender a questão do município de origem e destino. No caso aqui é um transporte interestadual e os municípios serão diferentes, porém na sugestão para preenchimento de globalização, cita:

Os campos de código(c) e nome(x) de município de início da prestação <cMunIni> e <xMunIni>  deverão ser preenchidos com um dos municípios de origem, quando forem vários os municípios de início, utilizando a tabela do IBGE 

e

Os campos de código(c) e nome(x) de município de término da prestação <cMunFim> e <xMunFim> deverão ser preenchidos com um dos municípios de término, quando forem vários os municípios de término.

Estes campos são preenchidos com as informações de origem e destino (estados diferentes), o tipo de CTE é Normal e não estou informando a tag <indGlobalizado>. Isto é, a SEFAZ está entendendo que estou tentando emitir um CTe Globlalizado mesmo não informando a tag <indGlobalizado>.

Poderiam me auxiliar para contornar esta rejeição?

[Luciano Alberti]

Na dúvida fui dar uma olhada no xml gerado e está gerando com <indGlobalizado>1</indGlobalizado>, mesmo não tendo informado isto no código. 

Percebi que é necessário explicitar que não é globalizado.

indGlobalizado := tiNao

Depois disso não rejeitou mais.

 

Editado 4 Outubro, 2017 por Luciano Alberti
encontrei a solução

[Italo Giurizzato Junior]

Boa noite Luciano,

Isso ocorreu porque os seus fontes estão desatualizados, pois essa propriedade esta com o valor default igual a tiNao.

[jek]

Ítalo,

Vi que esta alteração é referente ao commit revisão 13942, mas mesmo com este default declarado, após a inicialização o valor padrão continua sendo "tiSim".

Tentei reinstalar todo o ACBr, apaguei as DCUs, mas não tem jeito... e suspeito que esta declaração não funciona, pois acontece exatamente o mesmo comportamento com a propriedade indAlteraToma do TInfCteSub (que está declarada como "default tiNao" também desde a revisão 13986).

Por fim, fiz um teste criando um novo tipo T_Indicador e mudando a declaração do FindGlobalizado para ele, e constatei que o que influencia o valor padrão é a ordem em que os valores deste tipo são declarados, pois é sempre considerado o primeiro valor:

Se T_Indicador = (ti_Sim, ti_Nao), o default é ti_Sim
Se T_Indicador = (ti_Nao, ti_Sim), o default é ti_Nao

Não sei se estou me perdendo em alguma coisa aqui (e se for o caso, há uma solução?), mas peço por favor que verifique esta questão.

Obs: testado no Delphi 10.1 Berlin

[BigWings]

55 minutos atrás, jek disse:

Não sei se estou me perdendo em alguma coisa aqui (e se for o caso, há uma solução?), mas peço por favor que verifique esta questão.

A diretiva default <valor> na declaração da propriedade apenas controla como o Delphi vai salvar o conteúdo no .dfm. Se o valor for igual ao default, nada é gravado.

Citar

Note: Property values are not automatically initialized to the default value. That is, the default directive controls only when property values are saved to the form file, but not the initial value of the property on a newly created instance.

http://docwiki.embarcadero.com/RADStudio/Seattle/en/Properties

Além de inserir a diretiva é necessário inicializar no construtor.

constructor TIde.Create(AOwner: TCTe);
begin
  inherited Create;
  FToma03 := TToma03.Create;
  FToma4  := TToma4.Create( AOwner );
  FinfPercurso := TinfPercursoCollection.Create(Self);
  FindGlobalizado := tiNao;
end;

 

pcteCTe.rar

[Italo Giurizzato Junior]

Bom dia a todos,

Fiz a alteração e enviei para o repositório, favor atualizar os fontes e refazer os testes.

[jek]

Ítalo, sei que o resultado final é o mesmo, mas entendo que a sugestão enviada pelo BigWings é melhor do que o commit revisão 14006 na questão de organização do código, onde ele colocou no constructor do TIde a inicialização do FindGlobalizado e constructor do TInfCteSub a inicialização do FindAlteraToma.

E considerando a explicação do BigWings sobre o uso da diretiva default, elas poderiam ser removidas do código também, já que não são propriedades que podem ser setadas no DFM.

[Italo Giurizzato Junior]

Boa tarde Jek,

Realmente ficou melhor, já enviei para o repositório.

[Rafael Fonseca]

Já olhei o manual e vários post aqui. Mas ainda estou com dificuldades pra entender quando vou emitir um cte "Globalizado = tisim" e quando vou emitir "Globalizado =tinao". Alguém pode me ajudar.

[Italo Giurizzato Junior]

Boa noite Rafael,

Veja este link:

http://portalcte.fazenda.mg.gov.br/download/SP01_CT-e_Globalizado_v2.pdf

[Rafael Fonseca]

Muito Obrigado.

 

[Luiz Carlos de Lima]

Bom dia, Ontem coloquei a versao 3.0 em producao e começou os os prolbemas abaixo:

Poderiam me dar uma ajuda, Estou emitindo um CTe Globalizado, sendo vários remetentes de MG para Um destinatario de MT. Segui as regras do manual, mas mesmo assim continua com erro.

Vejam as mensagem de retorno:

UFIni  = UFfim  - CFOP 6353 – CFOP Invalido para Operacao

UFIni  = UFfim  - CFOP 5353 – CFOP invalido, informar 5932 ou 6932

UFIni  = UFfim  - CFOP 6932 – CFOP invalido para Operacao

UFIni  = UFfim  - CFOP 5932 – Codigo de Municipio diverge da UF de inicio da prestação

Entao Coloquei > Ide.cMunIni = Ide_cMunFim e Ide.xMunIni = Ide_xMunFim'

Erro: CTe Globalizado deve conter NFe com CNPJ diferentes para múltiplos remetente

Mas veja no XML que as chaves informadas sao de CNPJ diferentes.

Anexo XML, agradeço ajuda.

52171001526219000191570010000670171000670178-cte.xml

[José M. S. Junior]

2 horas atrás, Luiz Carlos de Lima disse:

Bom dia, Ontem coloquei a versao 3.0 em producao e começou os os prolbemas abaixo:

 

Poderiam me dar uma ajuda, Estou emitindo um CTe Globalizado, sendo vários remetentes de MG para Um destinatario de MT. Segui as regras do manual, mas mesmo assim continua com erro.

 

Vejam as mensagem de retorno:

UFIni  = UFfim  - CFOP 6353 – CFOP Invalido para Operacao

 

UFIni  = UFfim  - CFOP 5353 – CFOP invalido, informar 5932 ou 6932

 

UFIni  = UFfim  - CFOP 6932 – CFOP invalido para Operacao

 

UFIni  = UFfim  - CFOP 5932 – Codigo de Municipio diverge da UF de inicio da prestação

 

Entao Coloquei > Ide.cMunIni = Ide_cMunFim e Ide.xMunIni = Ide_xMunFim'

 

Erro: CTe Globalizado deve conter NFe com CNPJ diferentes para múltiplos remetente

Mas veja no XML que as chaves informadas sao de CNPJ diferentes.

 

 

Anexo XML, agradeço ajuda.

52171001526219000191570010000670171000670178-cte.xml

Bom dia, aparentemente esse CTe seria rejeitado devido a seguinte regra:

Se informado indicador de CT-e Globalizado (indGlobalizado) e Tomador do
Serviço for Destinatário:
- O número de remetentes (CNPJ diferentes) nas chaves de acesso das NFe
transportadas deve ser superior ou igual a 5.
* Verificar pelo CNPJ que compõe a chave de acesso. (Neste caso são apenas três notas)

[Luiz Carlos de Lima]

Citar

Realmente era isso, o problema é que não retorna o erro especifico exigindo igual ou maior que 5. Outro problema que notei é que ele exige que a UF inicial seja igual a UF final, daí dá erro no município Inicial que não existe na UF final, então informei também o município inicial igual ao final. Agora não sei o que vai dar com a fiscalização, pois no DACTE a Origem da prestação fica igual o Destino da prestação. 

Realmente era isso, o problema é que não retorna o erro especifico exigindo igual ou maior que 5. Outro problema que notei é que ele exige que a UF inicial seja igual a UF final, daí dá erro no município Inicial que não existe na UF final, então informei também o município inicial igual ao final. Agora não sei o que vai dar com a fiscalização, pois no DACTE a Origem da prestação fica igual o Destino da prestação. 

[José M. S. Junior]

Neste caso, acredito que não se enquadra no CTe Globalizado, por ser outra UF de destino...

[Luiz Carlos de Lima]

Bom dia, 

Continuo acreditando que deve haver algo errado aí. O manual diz que a UFIni  deve ser igual a UFFim   para CTe Global, mas não diz nada sobre cMunIni, só 

 

         Ide.UFIni   := FieldByName('Ide_UFIni').AsString;
         Ide.cMunIni := FieldByName('Ide_cMunIni').AsInteger;
         Ide.xMunIni := FieldByName('Ide_xMunIni').AsString;

         Ide.UFFim   := FieldByName('Ide_UFFim').AsString;
         Ide.cMunFim := FieldByName('Ide_cMunFim').AsInteger;
         Ide.xMunFim := FieldByName('Ide_xMunFim').AsString;

Outro problema que notei é que ele exige que a UF inicial seja igual a UF final, daí dá erro no município Inicial que não existe na UF final, então informei também o município inicial igual ao final. Agora não sei o que vai dar com a fiscalização, pois no DACTE a Origem da prestação fica igual o Destino da prestação. 

[Luiz Carlos de Lima]

Bom dia, 

Continuo acreditando que deve haver algo errado aí. O manual diz que a UFIni  deve ser igual a UFFim   para CTe Global, mas não diz nada sobre o cMunIni. Mas como é feito critica dos cMunIni  com o UFIni, obrigando que os cMunIni estejando contidos no UFIni, quando igualo o UFIni com o  UFFim , preciso também deixar o cMunIni igual ao cMunFim . então no DACTE a Origem da prestação fica igual ao Destino da prestação. 

Será que estou fazendo algo errado. Se algum tem algum esclarecimento agradeço. Anexei o XML e o DACTE.

52171001526219000191570010000670291000670292-cte.pdf

52171001526219000191570010000670291000670292-cte.xml

[José M. S. Junior]

Bom dia, verifique a rejeição 743 do manual do CT-e: Rejeição: CT-e Globalizado não pode ser utilizado para operação interestadual.

Pode informa municípios diferentes na origem e destino, desde que sejam da mesma UF.

[Luiz Carlos de Lima]

Realmente, eu tinha interpretado errado. Grato.

[murilo cosme da silva]

Boa tarde,

Alguém sabe como proceder para fazer uma CTe para fora com xml de diferentes emitentes, até antes desta atualização podíamos escolher um para ser o mandatário e dava tudo certo. 

[Italo Giurizzato Junior]

Bom dia Murilo,

Se você esta se referindo ao CT-e Globalizado, favor dar uma lida nas regras de validação: G271 até G281 que se encontram nas páginas 58 e 59 do Manual do CT-e versão 3.00