Gr@c@

Infelizmente não posso, porque nesse xml não constam os dados ficticios e/ou da minha empresa. São dados reais de um cliente. Mas posso ajudá-lo em alguma dúvida se precisar. Ou postar imagem de trechos do codigo do xml.

Não porque o Detran não quis disponibilizar os webservices para desenvolvimento. Disponibilizaram para uma empresa em específico. Uma máfia.

Não faz sentido. Se o emitente do MDF-e já é credenciado CT-e basta emitir o CT-e para a NF-e e declarar apenas os CT-e´s.

Não estou conseguindo de nenhuma forma. Fiz os seguintes testes (todos com o LT_TLSv1_2): SSLXmlSignLib = xsLibXML2 e renomeando os arquivos -OPENSSL.xsd --> erro 12002 timeout. SSLXmlSignLib = xsXmlSec e renomeando os arquivos -OPENSSL.xsd --> erro 12002 timeout. SSLXmlSignLib = xsXmlSec sem renomear os arquivos -OPENSSL.xsd e mantendo o original --> erro atomic type SSLXmlSignLib = xsLibXML2  sem renomear os arquivos -OPENSSL.xsd e mantendo o original --> erro atomic type

Entrei em contato com algumas transportadoras aqui e o que foi dito é que: se o RNTRC do cavalo não for o mesmo da empresa emitente do CT-e/MDF-e obrigatoriamente tem que ter o CIOT porque essa é a garantia que o terceirizado tem como garantia das despesas. Isso tanto para transporte estadual como interestadual.

Não uso openSSL. Mesmo usando a libWinCrypt tenho que usar os schemas modificados? Porque ainda continua o erro e renomeando as -OPENSSL.xsd dá esse erro

NT 2018/001. Esta rejeição abaixo passou a ser aplicada em produção a partir de 16/04/2018 Rejeição = Se modal rodoviário e informado RNTRC Verificar se foi informado CIOT quando este for obrigatório para o RNTRC ** Validação não se aplica a operações com exterior (UF Ini ou UF Fim = EX) Pergunta: quando o RNTRC é obrigado a informar o CIOT?

dando continuidade a esse topico, segue ainda uma dúvida: - se eu gerar uma carga contendo vários CT-e com a mesma placa, a mesma uf origem e mesma uf destino (nesse caso será gerado um único MDF-e), o CIOT irá ser distinto para cada CT-e ou será o mesmo para a carga toda? Ou seja, um CIOT para cada MDF-e e não um CIOT para cada CT-e?

Isso que vc mencionou está ocorrendo em MG com o CT-e. Funciona 100% em produção, mas em homologação não. Tanto é que consultando a disponibilidade em homologação, alguns serviços estão no vermelho e outros no amarelo. O seu caso é diferente do outro colega porque ele diz que funciona em alguns micros e outros não. No seu, acredito que seja no mesmo micro onde funciona produção e não funciona homologação. No seu caso, vc deve ver se ocorre o mesmo com outros programadores de SP.

Em 2 clientes meus onde ocorria isso, foi só formatar o micro e instalar o windows 7 professional sp 1 que resolveu o problema. Um cliente de MG e outro do MA. Não trabalho com SP. Mas se vc alega que funciona em uns e outros não, pode ser uma peculiaridade do windows mesmo. Primeiro verifique se são windows atualizados originais. Pq os piratê da vida só causa dor de cabeça.

Pensei na possibilidade de se criar um parametro nas configurações do ACBr para, quando ocorrer a rejeição "656-Rejeição: Consumo Indevido" ser acrescentado à mensagem de erro também a mensagem parametrizada para ser mostrada ao usuário. Por exemplo: "656-Rejeição: Consumo Indevido" "O contribuinte que estiver utilizando indevidamente os sistemas poderá sofrer as penalidades definidas na legislação da UF MG .....(aqui especificiar as penalidades)....Caso insista, sua empresa será bloqueada após 50 tentativas......." Motivo: Consumo indevido pode ser um erro provocado pela insistência do usuário ou por um erro do próprio desenvolvedor. Isso pode nos tornar co-responsáveis na multa/ou outras penalidades que a empresa usuária sofrerá. Se for criado esse parametro, não precisaremos tratar em toda a nossa aplicação a possibilidade da ocorrencia desse erro. Assim, sempre que houver a rejeição 656, o ACBrNFe (e outros) já traria a mensagem caso ela esteja parametrizada.

23/04/2018 - ATENÇÃO: Publicada NT 2018.002 prevendo novos controles sobre o consumo indevido dos ambientes de autorização. Publicada NT 2018.002 prevendo novos controles sobre o consumo indevido dos ambientes de autorização.

Estou com esse problema e estou usando o WinCrypt. Estou tentando em homologação MG.

20/04/2018 - ATENÇÃO: Publicada NT 2018.001 trazendo novidades na emissão de NF-e por Produtores Rurais. Publicada NT 2018.001 trazendo novidades na emissão de NF-e por Produtores Rurais.

verifique se: o windows 7 + service pack 1 + atualizações .Net Framework 4.6.2 ou superior wincrypt.dll atualizada e estou em duvida se aqui FrmPrincipal.AcBrNFE1.Configuracoes.Geral.SSLXmlSignLib := xsMsXml ====> não seria o xsMsXml2 (precisa ver com os colegas aqui do forum)

tentou assim? FACBrNFe.Configuracoes.Geral.SSLLib := libWinCrypt;FACBrNFe.Configuracoes.Geral.SSLCryptLib := cryWinCrypt;FACBrNFe.Configuracoes.Geral.SSLHttpLib := httpWinHttp;FACBrNFe.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2;

Mas esse xml está assinado e autorizado.

Tenho um cadastro de empresa com 2 campos: CRT e Regime Especial, sendo que o CRT é para atender a NFe e o Regime Especial para atender a NFS-e e outras situações. Existe algum vinculo entre essas 2 tabelas? Por exemplo: Quem é MEI(regime especial 5) está enquadrado em qual CRT? Ou não se enquadra em nenhum devendo ser criado um registro de CRT 0-NENHUM? Quem tem CRT 3 só pode ser 7-lucro real ou 8-lucro presumido? Ou seja, existe alguma validação a se fazer comparando as 2 informações? Um CRT só aceita determinados regimes especiais e vice-versa? Ou não se trata de informações cruzadas? CRT 1 SIMPLES NACIONAL 2 SIMPLES NACIONAL C/ EXCESSO DE SUBLIMITE DA RECEITA BRUTA 3 DEBITO CREDITO REGIMES ESPECIAIS 0 NENHUM 1 MICRO EMPRESA MUNICIPAL 2 ESTIMATIVA 3 SOCIEDADE PROFISSIONAIS 4 COOPERATIVA 5 MICRO EMPRESARIO INDIVIDUAL 6 MICRO EMPRESARIO EMPRESA PP 7 LUCRO REAL 8 LUCRO PRESUMIDO 9 SIMPLES NACIONAL 10 IMUNE 11 EMPRESA INDIVIDUAL RELI 12 EMPRESA EPP 13 MICRO EMPRESARIO 14 OUTROS

Sim já ocorreu com um cliente meu. O que ocorre é que tem que aguardar um tempo para que haja a distribuição do cancelamento do MDF-e para as UF´s.

Essa noticia é antiga, de 2017.

Parece que MG emperrou de novo:(resposta do SEFAZ quando questionei sobre a liberação dos webservices de homologação prevista para abril e obrigatoriedade para julho/2018) O Projeto Piloto da NFC-e ainda não iniciou em MG e a legislação estadual não foi publicada. Conforme informações da superintendência responsável ainda não foi divulgada uma nova previsão para início da atividade. Gentileza acompanhar publicação de novas informações sobre a NFC-e no Portal Estadual do SPED em http://www.sped.fazenda.mg.gov.br/spedmg/nfce/

Mas vc tentou pedir para o tomador fazer o evento em desacordo? E, após ele fazer esse evento, vc fazer somente o CT-e substituto referenciando o CT-e substituido (que nesse momento já deverá ter o evento em desacordo vinculado)? Você não vai fazer um ct-e de anulação( o evento em desacordo substitui ele ). Vai fazer somente o substituto.

Quem tem que fazer o evento de Prestação em desacordo é o tomador, da mesma forma como era ele quem fazia a NFe de anulação. Assim, quando o CT-e tem o evento de desacordo vinculado a ele, a transportadora consegue fazer o CT-e substituto. Mas como fica quando o tomador não tem certificado digital pra fazer o evento?

Acabei de realizar os testes e a NFC-e foi autorizada, portanto todas as respostas dos colegas acima estão corretas: -Ambiente = homologação -Emitente da NFC-e = Maranhão -Destinatario da NFC-e = MG (coloquei os dados reais do endereço) -Ide.idDest = doInterna -CFOP = 5405 para as mercadorias com ST/5102 para mercadorias normais -Venda = presencial