Scott

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.

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.

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.

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. 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.

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

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é?):

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.

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

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>

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.

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: Eles querem dizer que com esses novos campos isso poderá ser possível no futuro, mas isso não está implementado agora.

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.

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)

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.

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.

Bom, a legislação diz o seguinte: 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.

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.

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.

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.

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.

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 (...)

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

O ambiente de homologação não acessa o de produção. Você precisa usar uma NF-e emitida também em homologação.

É 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.

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.