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.