Gr@c@

sim, MG está com problemas. Temos outro tópico a respeito no forum

MG paralisação programada das 18h do dia 15/03 às 12h do dia 20/03

Bom dia. MG está com problemas para emissão de qualquer DF-e. Na parte da manhã, ainda se conseguia emissão por SVCAN, mas não está funcionando mais. O portal Estadual de MG e o SIARE também se encontram fora do ar. Não há absolutamente nada a fazer por parte do ACBr. Temos que aguardar que os serviços sejam disponibilizados. Infelizmente podemos perceber que no portal da NFe todos os serviços de MG estão em verde o que não representa a realidade.

Se vc é desenvolvedor e seu CNAE não permite venda a consumidor, o seu CSC vale somente para homologação. Isso eles deixam claro no email que enviam com o CSC. Você também pode validar o xml no validador do RS para ver se existem outros erros no seu xml.

Esse CFOP 5949/6949 realmente não é aceito para devolução. Vc precisa confirmar se trata-se de uma "Remessa em garantia", nesse caso, pode ser usado o 5949/6949 como tipo de emissão normal, referenciando a nota de compra. Se for para conserto/reparo tem CFOP específico (5915/6915).

verifique no Layout do CTe as informações ref a rodo (ref ao modal rodoviario). Cada modal tem tags específicas que devem ser informadas. -<rodo> <RNTRC>01245123</RNTRC> </rodo>

Você não consegue informar o valor do campo já arredondado pelo seu sistema?

É só você colocar essas informações no campo de observações.

Deve ser falta do campo vIcmsSubstituto que entrará em vigor somente em abril.

Por favor verifique esse tópico:

Com os fontes atualizados do ACBr, está tudo funcionando. Está ocorrendo o erro 12002 TimeOut. Para solucionar, coloque um timeout de 35 segundos. Está bem lento o retorno da SEFAZ/MG e eles já reconheceram o problema.

Atualização no svn 16576

deve ser informada a tag CPF com 11 digitos exemplo: <CPF>00000000191</CPF>

Tem vários sites, porem muita informação controversa. Sugestões: portal da ANTT http://www.antt.gov.br/ Truckpad https://blog.truckpad.com.br/gestao/ciot/ Guia do TRC http://www.guiadotrc.com.br/leidociot/default.asp

Para resolver a Rejeição 464, verifique todos os seguintes pontos: Se o Token para Homologação está configurado, veja se está enviando para o ambiente de homologação e vice-versa; Configurar o Token exatamente igual ao disponibilizado no portal da SEFAZ. Incluir traços, quando existir; Se o Token foi configurado apenas copiando e colando, tente digitar ele no campo determinado. E se ele foi configurado digitando, tente copiar do portal da SEFAZ e colocar no campo determinado; Confirme se os dados do Token e IDToken configurados estão exatamente iguais aos disponibilizados pela SEFAZ, no portal; Confirme se o IDToken possui 6 dígitos. Exemplo: No caso de ID 1, o valor configurado deve ser 000001; Verifique se os dados não foram configurados nos campos invertidos. Por exemplo, verifique se o Token não está configurado no campo IDTokenNFCe e vice-versa; Em alguns casos, caracteres especiais como o "&" (e comercial), podem apresentar essa rejeição, porém, depende do tratamento que a SEFAZ realiza; Se nenhum dos passos anteriores resolveram o problema, tente revogar o Token (CSC) e gerar um novo; Se todos os processos acima foram realizados e o erro ainda persiste, entre em contato com o escritório de contabilidade do cliente e confirme todos os dados. Se mesmo assim o erro persistir, existe a possibilidade de que a SEFAZ esteja retornando a rejeição incorreta. Por exemplo, o XML está com uma falha de esquema, mas a validação da SEFAZ retorna que o Hash do QR Code difere do calculado. Esses casos são raros, mas podem existir. Caso chegue a esse ponto, a melhor medida, é entrar em contato com a própria SEFAZ e verificar qual a ocorrência.

1ª: Recebi apenas um código alfanumérico contendo 32 caracteres dizendo ser o CSC, o que seria esse idCSC/idToken? CSC=codigo que você recebeu de 32 caracteres IDCSC=1

parece que o conteudo informado em CPF= não corresponde a um numero de CPF válido

Vc precisa solicitar uma consultoria para analisar esse tipo de operação, porque não sei se ela se enquadra nos critérios da subcontratação. Ao meu ver deveria ser emitido um CT-e normal.

vc tentou essa tag? <idDocAntPap> <tpDoc>02</tpDoc> <serie>123</serie> <nDoc>114212</nDoc> <dEmi>2011-05-08</dEmi> </idDocAntPap> With infCTeNorm.docAnt.emiDocAnt.Add do begin CNPJCPF := DM.qryFreteNfs.FieldByName('CpfCnpj').AsString; IE := DM.qryFreteNfs.FieldByName('InscricaoEstadual').AsString; UF := DM.qryFreteNfs.FieldByName('UF').AsString; xNome := DM.qryFreteNfs.FieldByName('RazaoSocial').AsString; With idDocAnt.Add.idDocAntPap.Add do begin // TpcteTipoDocumentoAnterior = (daCTRC, daCTAC, daACT, daNF7, daNF27, daCAN, daCTMC, daATRE, daDTA, daCAI, daCCPI, daCA, daTIF, daOutros); tpDoc := daOutros; serie := Trim(Copy(DM.qryFreteNFs.FieldByName('SerieNF').AsString+space(3),1,3)); subser := ''; nDoc := DM.qryFreteNFs.FieldByName('NFiscal').AsString; dEmi := DM.qryFreteNFs.FieldByName('DTEmissao').AsDateTime; end; end; end;

esse xml de exemplo possui documentos anteriores. Notei que os documentos anteriores são as própries NFe referenciadas.

Você disse que a empresa que terceirizou o serviço não emite CT-e. Essa empresa é uma transportadora? Porque a subcontratação exige um documento anterior, no caso um CT-e emitido pela transportadora que está subcontratando outra. veja esse link http://www.ophos.com.br/app/publicacoes/detalhe/ct-e-de-subcontratacao/

verifique esse tópico

Aparentemente não. Tente validar o seu xml no validador do RS https://www.sefaz.rs.gov.br/nfe/nfe-val.aspx

Precisa se credenciar para obter o CSC mesmo em homologação, ou usar o CSC+certificado de um cliente que já seja credenciado.