Vitor Felipe Carvalho

Claro, segue em anexo um exemplo. Lembrando que antes de enviar para a sefaz você deve encapsular com o seguinte XML, compactar usando algum algoritmo de GZIP e depois encodar em base64. <cteDadosMsg xmlns="http://www.portalfiscal.inf.br/cte/wsdl/CTeRecepcaoSincV4">XML compactado em GZIP e encodado em base64</cteDadosMsg> Para facilitar, eu indentei o xml. Mas segundo o manual você deve remover os espaços entre as tags antes de enviar também. exemplo_cte_4.0.xml

Estou usando outro software para emitir CT-e então não posso te dizer com certeza se vai precisar modificar algo no ACBrDFe, entretanto não precisei fazer nenhuma modificação em relação aos webservices dos outros estados para conseguir emitir. Até o momento testei tanto a emissão quanto o cancelamento, sem problemas em MG (o único problema que tenho em relação ao CT-e 4.0 é o cancelamento no PR, que não funciona por algum erro interno no sistema deles)

Hoje o serviço saiu de contingência e consegui aprovar o primeiro CT-E 4.0 no ambiente de produção em MG sem ser pelo SVC-SP.

Estava com os mesmos "sintomas", sempre que ia consultar geralmente já estava bloqueado, mesmo esperando muito mais que uma hora entre as consultas e sempre consultando a partir do ultimo NSU. Tentei consultar o NSU 0 depois de esperar o "castigo" de 1 hora e nada, sempre bloqueado. Investigando mais a fundo, descobri que o ERP da empresa também fazia consultas no webservice de distribuicaoDFe. Foi desativar essa funcionalidade do ERP que a consulta no meu sistema voltou a funcionar perfeitamente, usando o mesmo certificado para consultar mais de 10 CNPJs (simultaneamente para cada cnpj, descartando a hipotese do bloqueio ser por certificado). Ou a sefaz corrigiu o problema exatamente no momento em que estava testando, ou realmente esses problemas são decorrentes de mais de um sistema competindo pelo uso da API, atrapalhando a linearidade do NSU.