Gr@c@

Então o que está faltando é credenciar o emissor em produção.

Não sei qual o seu estado, mas aqui em MG se o emissor já é credenciado para emissão de CT-e ou NF-e ele já fica credenciado para emissão de MDF-e. Verifique junto ao órgão responsável pelo seu estado. Se for MG verifique no SIARE.

No validador de cte do RS está dando: PARSER XML: OK TIPO DE MENSAGEM: Tipo de Schema não tratado: cteOSProc

Segue resposta da SEFAZ/MG:

Ok. Só evita escrever em letras maiúsculas pq as regras do forum não permitem. Assim q tiver retorno do Sefaz posto aqui.

Soube por um grupo de NFC-e MG que algumas empresas de MG foram escolhidas como voluntárias para envio de NFC-e. Não sei lhe dizer quais. Mas nada foi liberado ainda, nem para desenvolvedores nem para as demais empresas.

Pelos testes que fiz aqui, 0=Contratação do Frete por conta do Remetente (CIF) , 1=Contratação do Frete por conta do Destinatário (FOB) exigem informações de transportadora e 2=Contratação do Frete por conta de Terceiros exigem informação de transportadora. Vou enviar email ao SEFAZ e pedir maiores esclarecimentos.

Aqui em MG começou essa rejeição também hoje.

Não precisa ser muito criativo para inventar código de barras. Existe rotina que cria codigo de barras que passam pela NFe e não são cadastrados no GS1. Por enquanto, esses códigos ainda não estão sendo validados junto ao cadastro do GS1, mas o SEFAZ já deixou claro que isso será feito, porém essa validação foi prorrogada para dar tempo às indústrias de se adequarem. Além do mais, o próprio GS1 ainda não disponibilizou uma API para consulta dos códigos cadastrados (somente clientes do GS1 tem acesso a essa consulta). Então, por hora, o que resta a fazer é o comprador exigir do fornecedor códigos de barra reais e credenciados ou a substituição do cEAN por "SEM GTIN". Agora, no seu exemplo, existe uma outra forma de diferenciar a entrada desses produtos que é pelo código original de fábrica (cProd), que são diferentes para cada produto. No meu aplicativo, ao importar o xml, eu levo em consideração cEAN + cProd.

os serviços do CT-e em MG está muito instável. Ora consegue enviar, ora dá rejeição do tipo 12002, 12175, 12030...Porém a contingência está normal.

Vi no cadastro do GS1 que tem como cadastrar o GTIN por grupo de produto. Por exemplo: um cliente industria de calçados tem a opção de cadatrar o GTIN grupo Botina e dentro dele ter a numeração de 34...até 44 ou cadatrar um GTIN para cada Botina + numeração, então teria um GTIN para botina 34, outro para a 35... Nesse caso aí do seu exemplo, trata-se de um produto de marca renomada no Brasil então pode ser o caso de GTIN por grupo porque o que está variando é apenas a cor.

aqui em MG temos que aumentar o timeout para, no mínimo, 20000 devido ao erro de timeout.

A impressora está na COM4. Resultado da procedure (a impressora está na COM4). --------------------------- EMISSOR NFCe --------------------------- COM2 - Erro: 9992-Instance already in use COM4 - Erro: 9992-Instance already in use --------------------------- OK ---------------------------

Aparece somente no status. No painel o led fica apagado.

Vale a pena ler e corrigir possiveis falhas no aplicativo emissor, porque essa rejeição de Consumo Indevido tanto poderá ser causada por erro do usuário (como insistência em ficar enviando NFe com erro) como pelo aplicativo (consulta em loop). Link NT 2018.002 - v 1.00 Consumo Indevido http://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=tW+YMyk/50s= Os prazos previstos para a implementação das mudanças são: o Ambiente de Homologação (ambiente de teste das empresas): 02/05/2018 o Ambiente de Produção: 16/05/2018

Ambiente: Impressora Elgin i9 ACBrNFe+ACBrPosPrinter+ACBrDANFeESCPOS Impressora sempre detectando Pouco Papel mesmo com bobina cheia ou nova. Seria sensor com defeito, configuração ou uma característica própria desse modelo de impressora? Na MP-4200 TH não ocorre.

Existem casos que, ao se instalar novo dispositivo, a porta COM da impressora fiscal passa a não ser mais a mesma configurada no aplicativo emissor de NFC-e. Como localizar via Delphi a porta serial em que a impressora não fiscal está, assim como a Bemafi32.dll faz?

Consultar status várias vezes, ficar tentando enviar uma NFe com rejeição de algo que tem que ser corrigido (ex: NCM inválido), consultar uma NFe varias vezes, enviar requisição e não aguardar tempo previsto pela SEFAZ para enviar uma nova requisição.

Encontrei algumas coisas na net sobre "obrigatoriedade da emissão da NF-e PR" a partir de 01/Jan/2019. No portal do SEFAZ fala-se em ser possivel emitir essa nota por uma aplicativo do contribuinte. No caso que citei, quem emite a nf-e é o frigorifico e não se trata de nota avulsa. Fica o questionamento: será que o frigorifico ainda poderá emitir essa NF-e como nota de compra? No xml dessa NF-e os envolvidos são: Emitente -> frigorifico Destinatario -> produtor rural CFOP -> 1101,2101 <natOp>COMPRA PARA INDUSTRIALIZACAO (GADO)</natOp>

Pra realizar esses testes vamos precisar dos fazendeiros ? ?do ACBr que tenham Inscrição PR + Certificado e-CPF. Atualmente, para venda de gado, o produtor rural emite uma GTA (existe um órgao que faz isso), mas é o frigorífico que emite uma NF-e de entrada ref a compra desse gado. Será que a partir de agora, o produtor que deverá emitir a NF-e de venda? Não tenho encontrado nada na net e o SEFAZ, como sempre, é bem superficial no assunto.

Em Homologação contingência SVC-AN Rejeição = 2999-Falha nao tratada. Mesmo que o erro seja só em homologação, estamos fritos do mesmo jeito porque se precisar de uma alteração não temos como testar o envio da NFe. E outra: não se sabe a origem desse erro e, com certeza, o SEFAZ/MG não nos dará um parecer a respeito. Já enviei reclamação no Fale Conosco.

Acabei de testar o envio de uma NF-e em homologação MG e deu o erro: "Rejeição: XML da área de dados com codificação diferente de UTF-8" Em produção, pelo menos até as 12:00hs, os clientes estavam enviando nota normalmente. Não sei se ocorreu o erro após isso, mas até agora ninguém reclamou.

Sim, mas algumas vezes funciona.