[Insucesso na Entrega - CTe 4.00 - Permitindo mais que um evento por CTe]

Olá,

Conforme a documentação na Nota Técnica 2023.002 o sequencial do evento aceita os valores entre 1 e 999, então é possível sim gerar vários eventos.

A outra regra relacionado a isso é essa aqui:

Essa regra diz que não pode existir dois eventos de insucesso autorizados, exceto para CT-e globalizado. 

O status de "autorizado" citado nessa regra é importante. Como existe o evento de cancelamento de insucesso, nada impede de emitir um evento de insucesso, emitir um evento de cancelamento de insucesso para o evento anterior, emitir um insucesso de novo, cancelar de novo, emitir um terceiro insucesso...

O que não pode acontece é, para um CT-e não globalizado, ter mais que um evento de insucesso na situação autorizado.

[Cte.webservices.retorno não funciona?]

Olá,

No CT-e 4.00 o serviço de recepção de CT-e é síncrono, ou seja, a resposta se o CT-e foi aprovado ou não vem já na chamada do webservice de Envio. Não existe mais o fluxo assíncrono, chamando o "Enviar" e depois chamar o "Retorno" para verificar a aprovação.

 

[Erro Elemento cteCabecMsg inexistente no SOAP Header na Inutilização de Numeração v4.0]

Olá,

Não existe serviço de inutilização do CT-e 4.00 e ele também foi desativado essa semana no CT-e 3.00 conforme Nota Técnica 2023.001.

No Ajuste SINIEF 31/22 o trecho da legislação do CT-e que falava sobre a necessidade de inutilizar os números não usados foi revogado, com efeito desde 01/06.

Ou seja, desde o início do mês essa função não é mais necessária e agora nem pode ser mais usada pq os serviços foram desativados na SEFAZ tbm.

[Contigência - quais as formas a partir de 28/06/2023]

11 hours ago, sergiom said:

LINHA 2431

ACBrCTeDACTEFR.pas

      if (FCTe.ide.TpEmis = teContingencia) or (FCTe.ide.TpEmis = teFSDA) or (FCTe.ide.TpEmis = teSCAN)      
 

não deveria estar com

      if FCTe.ide.TpEmis in [teContingencia, teFSDA, teSVCSP, teSVCRS, teSCAN]

 

Não, porque a única forma de contingência que exige a expressão "DACTE em Contingência - impresso em decorrência de problemas técnicos" no corpo do DACTE é a contingência em formulário de segurança.

5 hours ago, sergiom said:

As outras contingência nós temos que enviar novamente à receita?

Pra ficar mais claro:

- Contingência em FS-DA: imprime o DACTE sem aprovar o CT-e usando o papel especial para FS-DA com um layout específico e mandar o XML pra SEFAZ quando o serviço voltar a ficar disponível.

- Contingência em EPEC: aprovar o evento EPEC na SVC que atende a UF, imprimir o DACTE em papel normal e depois mandar o XML pro ambiente normal da UF quando o serviço voltar a ficar disponível.

- Contingência em SVC: aprovar o CT-e na SVC que atende a UF e imprimir o DACTE normalmente, como qualquer outro DACTE sem precisar de nenhuma indicação especial. O XML não precisa ser enviado pro ambiente da UF depois.

[Disponibilidade para SP esta tudo parado mesmo pessoal?]

Sim, a SVC-RS está disponível, tem o aviso no site da SEFAZ de SP: https://portal.fazenda.sp.gov.br/servicos/cte

Quote

26/06/2023 - Manutenção CT-e 
Informamos que o ambiente de autorização do CT-e está em manutenção para a ativação da versão 4.00, com indisponibilidade temporária, a SVC-RS está disponível para os contribuintes.

 

[CTe 4.0 - Grupo ICMSSN, campo CST]

Cleber, isso foi um erro na publicação do manual do 4.00 e publicaram a correção na Nota Técnica 2023.001 (poderiam ter corrigido o manual tbm né?):

[[Duvida] Schemas]

Olá,

O motivo é o mesmo... No CT-e 4.00 existe apenas o envio pelo serviço síncrono e não existe mais a formação de lotes de CT-e (que era o que o schema enviCTe definia). O serviço de recepção recebe agora o CT-e diretamente, ou seja, o conteúdo com "<CTe xmlns="http://www.portalfiscal.inf.br/cte"><infCte..." sem a tag "enviCTe" por fora.

[Erro emissão cte na versão 4.0 em homologação]

Isso acontece pq o soapAction do servidor do MG está diferente das outras UFs, erro deles...

Se pegar o WSDL do CTeRecepcaoSincV4 de todos as outras UFs vai ter lá 

<soap12:operation soapAction="http://www.portalfiscal.inf.br/cte/wsdl/CTeRecepcaoSincV4/cteRecepcao"/><soap12:operation soapAction="http://www.portalfiscal.inf.br/cte/wsdl/CTeRecepcaoSincV4/cteRecepcao"/>

<soap12:operation soapAction="http://www.portalfiscal.inf.br/cte/wsdl/CTeRecepcaoSincV4/cteRecepcao"/>

Mas em MG atualmente está sssim:

<soap12:operation soapAction="http://www.portalfiscal.inf.br/cte/wsdl/CTeRecepcaoSinc/cteRecepcao"/>

Note que no soapAction deles está só CTeRecepcaoSinc em vez de CTeRecepcaoSincV4, por isso retorna o erro que não conseguiu chamar o método, pq o ACBr está tentando com CTeRecepcaoSincV4

[Literal da tag xNome no CTe 4.0 em homologação]

Pior que fiz o teste em SP também, e lá só aprova com hífen como era no CT-e 3.00:

<retCTe xmlns="http://www.portalfiscal.inf.br/cte" versao="4.00">
	<tpAmb>2</tpAmb>
	<cUF>35</cUF>
	<verAplic>SP-CTe-2023-05-23-1</verAplic>
	<cStat>646</cStat>
	<xMotivo>Rejeição: CT-e emitido em ambiente de homologação com Razão Social do remetente diferente de CT-e EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL.</xMotivo>

[Nota de Anulação de Frete / Prestação de serviço em desacordo]

Não existe alternativa para o 3.00, a NT 2023.001 é bem clara nisso: O CTe com tipo anulação e substituição deixam de existir na versão 3.00.

Foi criada até regra de validação impedindo a aprovação de CT-es de substituição na versão 3.00.

Isso só será possível novamente quando no 4.00.

[Informações CIOT no MDFe]

16 hours ago, toninho said:

Boa tarde, se informar os campos sobre o Pagamento do Frete no MDF-e não preciso fazer o CIOT.

SIm, precisa.

A nota técnica não cita nenhuma mudança com relação ao retorno 684 (Rejeição: CIOT obrigatório para RNTRC informado. / Se modal rodoviário, UF Carregamento e Descarregamento forem diferentes de Exterior e informado RNTRC: Verificar se foi informado CIOT quando este for obrigatório para o RNTRC).

Entendo que quando a NT diz:

Quote

 

Publicação dessa NT, que estrutura o MDF-e de forma a possibilitar, entre outros benefícios:

* o Geração automática do CIOT, pelo Sistema MDF-e, tanto para as modalidades TACIndependente como TAC-Agregado

 

Eles querem dizer que com esses novos campos isso poderá ser possível no futuro, mas isso não está implementado agora.

[Cancelamento de CT-e - 2 formatos?]

O layout procCancCTe era o formato de cancelamento de CT-e até o 1.04. Se tiver alguém mandando esse formato ainda para os CT-es 2.00 está fazendo errado.

No 2.00 o serviço de cancelamento foi removido e passou a ser um evento, gerando portanto um procEventoCTe.

[Nota Técnica 2015/001]

arce, CFOP iniciado em 5 é transporte que começa e termina na mesma UF, se for iniciado em 6 é porque as UFs de início e fim são diferentes.

 

Então pegando como exemplo uma transportadora de SC:

 

UFini = RS

UFFim = RS

CFOP = 5932 (transporte dentro da mesma UF)

 

UFini = PR

UFFim = RS

CFOP = 6932 (transporte envolvendo UFs diferentes)

[525 Rejeicao: Carta De Correcao Invalida (Campo/grupo [Cfop] Informado Nao Existe No Schema Do Ct-E Ou Nao Existe No Grupo Informado)]

Tenta informar "dest" invés de "Dest", pois a tag do xml é com o d minúsculo. Pode ser que a validação da SEFAZ-SP seja mais rígida.

[Carta De Correção - Segunda Emissão]

...

 

Quando precisar emitir uma outra correção, os campos já corrigidos na CCe anterior não poderão aparecer na nova, e o campo Sequencia de evento tem que ser incrementado.

 

Leandro, isso está errado. O manual do CT-e diz o seguinte: o registro de uma nova Carta de Correção substitui a Carta de Correção anterior, assim a nova Carta de Correção deve conter todas as correções a serem consideradas.

 

Ou seja, quando precisar emitir uma nova correção, você deve mandar todas as correções anteriores e adicionar/remover o que você precisa.

[Mdfe Entrada]

Bom, a legislação diz o seguinte:

 

Cláusula terceira O MDF-e deverá ser emitido:

(...)

II - pelo contribuinte emitente de NF-e de que trata o Ajuste SINIEF 07/05, de 30 de setembro de 2005, no transporte de bens ou mercadorias acobertadas por mais de uma NF-e, realizado em veículos próprios ou arrendados, ou mediante contratação de transportador autônomo de cargas.

(...)

§ 7º Na hipótese estabelecida no inciso II desta Cláusula, a obrigatoriedade de emissão do MDF-e é do destinatário quando ele é o responsável pelo transporte e está credenciado a emitir NF-e.

 

 

Confesso que nunca precisei emitir um MDF-e pra nota de entrada, então não sei se as validações pelo webservice foram atualizadas para permitir isso ou não. Olhando as notas técnicas, me parece que sim. Ele não obriga mais que o emitente do MDF-e seja o mesmo da NF-e. Mas só fazendo um teste mesmo pra confirmar.

[Rejeição Data Do Evento Nao Pode Ser Maior A Data Do Processamento]

Não tem muito o que fazer além de você ajustar a data no XML antes de mandar. Pelo que percebi hoje, a SEFAZ do SP e a do PR não mudaram o fuso para o horário de verão.

[Consulta Mdf Em Aberto]

Se você não conseguir o DAMDFE impresso anteriormente, você vai precisar pelo menos saber o motorista, veículos e UFs de carga e descarga desse que foi perdido.

 

Com isso você pode tentar emitir um MDF-e novo para ele. A SEFAZ deve recusar dizendo que já existe um manifesto não encerrado para esse conjunto. Nessa mensagem vai ter a chave do MDF-e que você perdeu. Com a chave, usa o webservice de consulta de status e aí você vai ter o protocolo de autorização. Com isso, você pode encerrar o MDF-e.

 

Outro detalhe que vale a pena lembrar: "como verificar se o motorista que estamos carregando tem algum manifesto em aberto em outras empresas ??"

 

Não importa. Um motorista pode tranquilamente ter vários manifestos em abertos pra outras empresas. E independente do que você queira fazer isso nunca vai fazer diferença nenhuma pra tua empresa. 

[Rejeição Cce - Cte]

Tente deixar o nroItemAlterado vazio. Não precisa informar 1 porque não tem como informar várias tags compl ou xObs no CT-e.

[Consultar Motorista]

Mateus, você está se confundindo e causando ainda mais confusão para quem quer ajudar...

 

Veja só, você disse que "consta aquela mensagem que o lugar de embarque é diferente do local do desembarque". E depois "por outras experiencias, eu sei que tem manifestos em aberto". Isso não faz sentido porque uma coisa não tem nada a ver com a outra. Se ele tivesse manifestos não encerrados, a mensagem seria "Rejeição: Existe MDF-e não encerrado para esta placa, UF carregamento e UF descarregamento em data de emissão diferente".

 

Segundo, o fato do motorista transportar para outras empresas não faz diferença nenhuma, vide que essa validação de MDF-e não encerrado é feita conforme os seguintes critérios conforme especificado no manual do contribuinte da SEFAZ: mesmo CNPJ base do emitente do MDF-e, mesma placa, mesma UF carregamento, mesma UF descarregamento e Data de emissão diferente. Veja que ela verifica o CNPJ junto. Os MDF-es emitidos por outras empresas NÃO são considerados.

 

Como o Brito já pediu e você não respondeu: a rejeição que é retornada pra você é que o Local de Embarque é diferente do Desembarque ou que ainda há uma MDF-e ainda não encerrado para este UF de embarque e UF de desembarque com este veículo?

 

Favor informar a mensagem exata que ocorre no seu caso. Procurei no manual por alguma mensagem relacionada ao que você comentou inicialmente e não encontrei nada.

[Único Evento Multiplas Correções]

 

No final, fica assim:

<eventoCTe xmlns="http://www.portalfiscal.inf.br/cte" versao="2.00">
  <infEvento Id="ID1101101234567890123456789012345678901234567890123401">
    <cOrgao>35</cOrgao>
    <tpAmb>2</tpAmb>
    <CNPJ>12345678901234</CNPJ>
    <chCTe>12345678901234567890123456789012345678901234</chCTe>
    <dhEvento>2014-08-13T16:01:50</dhEvento>
    <tpEvento>110110</tpEvento>
    <nSeqEvento>1</nSeqEvento>
    <detEvento versaoEvento="2.00">
      <evCCeCTe>
        <descEvento>Carta de Correcao</descEvento>
        <infCorrecao>
          <grupoAlterado>dest</grupoAlterado>
          <campoAlterado>fone</campoAlterado>
          <valorAlterado>4545454545</valorAlterado>
        </infCorrecao>
        <infCorrecao>
          <grupoAlterado>enderDest</grupoAlterado>
          <campoAlterado>nro</campoAlterado>
          <valorAlterado>500</valorAlterado>
        </infCorrecao>
        <infCorrecao>
          <grupoAlterado>enderDest</grupoAlterado>
          <campoAlterado>xBairro</campoAlterado>
          <valorAlterado>CENTRO</valorAlterado>
        </infCorrecao>
        <xCondUso>A Carta de Correcao (...)

[Cancelamento Cte Rejeição Erro 630]

tidra, o descEvento tem que ser "Cancelamento" exatamente. No teu xml está "cancelamento" com o 'c' minúsculo.

[Erro No Envio/consulta Ct-E Devido Nf-E]

O ambiente de homologação não acessa o de produção.

 

Você precisa usar uma NF-e emitida também em homologação.

[Ct-E Com Nf-E Emtida Em Contigência]

É a mensagem 661 (Rejeição: NF-e inexistente na base de dados da SEFAZ)?

 

Se for isso, a validação na SEFAZ não está correta, já que o manual deixa claro que não é necessário validar para NF-es emitidas em contingência. 

 

Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e informados grupos de informações de documentos (infDoc) e NF-e (infNfe), para cada uma das NF-e´s relacionadas: 

 - Acessar BD CHAVES NFE (Chave: CNPJ Emit, Modelo, Série, Nro): 

 - Verificar se NF-e não existe 

Retornar a primeira chave de acesso de NF-e inexistente. 

 

OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no Ambiente Nacional através de WebService nfeConsultaNFe. 

OBS: NF-e em contingência fica dispensada dessa validação (verificar tpEmis da chave de acesso da NF-e) 

 

 

[Cte Complementar]

vierra, se você abrir o MOC 2.00a, página 27, vai ver que os eventos são: Carta de Correção, Cancelamento, EPEC e Registros do Multimodal. Como o pessoal já disse antes, o complementar é como um CT-e normal, apenas mudando a tag tpCte e mais uns campos.