Gustavohq

Bom dia, o problema foi solucionado, aparentemente problemas na SEFAZ/MG, pode ser encerrado.

Boa tarde, após ver em outro tópico que a TK-4663 havia sido analisada, tentei realizar novamente um envio do evento de Insucesso e dessa vez já tive algum retorno, porém com a rejeição mostrada na imagem abaixo, tanto no nosso sistema como no programa exemplo. No entanto, tanto a NF-e quanto o CT-, que possui esta NF-e vinculada, foram transmitidos sem falha. O que pode estar causando esta rejeição? Seria algo para verificar com a SEFAZ? Os XML's também estão em anexo. Desde já, grato! CTe31231110579567000118571030000001021823222982-cte.xml 31231110579567000118551030000000251835864200-nfe.xml

Boa tarde, procurei e não encontrei em nenhum tópico algo referente a isso. Estamos testando o envio do evento de Insucesso na entrega do CT-e porém, só é retornada uma mensagem vazia, como pode ser visto no print abaixo: Realizei um teste utilizando o programa exemplo da ACBr e também retornou um erro sem mensagem e no log mostrou: Notei que no log o Ambiente aparece como 1, onde na consulta acima pode ser visto, que estava definido a homologação (2). Seria algo para se verificar com a SEFAZ? Desde já grato!

Boa tarde, tive um cliente com esse mesmo problema semana passada e solicitando essa possível correção. Verificaram sobre a inclusão ou não no SVN? Desde já grato!

Obrigado pelo retorno Nilton, também deixei pronto, aguardar a obrigatoriedade agora!!

Quase um mês depois e ainda não consegui enviar em MG, alguém já conseguiu enviar essa tag que possa me ajudar?

Obrigado pelo retorno Renato, a alteração foi feita e o resultado ocorreu como esperado, em anexo a Unit alterada. ACBrEPCBloco_C_Class.pas

Boa tarde a todos! Estamos realizando uma alteração na geração do nosso Sped Pis/Cofins e me deparei com esta situação. A alteração consiste no possível não envio do NCM de produtos dos tipos 07/08/09/99 para o SPED, tanto no registro 0200 quanto para os C180 e C190. No registro 0200 o campo é enviado vazio como definimos, porém, nos registros do bloco C, ao verificar o arquivo de escrituração, encontramos os campos preenchidos com zeros mesmo enviando vazio como no 200. Gostaria de saber porque é enviado o zero e como posso proceder para que o envio dos registros C180 e 190 funcione como no 0200, se for possível claro. Como podem ver somente os produtos dos tipos 00 e 10 mostram o NCM no registro 0200. E abaixo no C180 os produtos marcados como exemplo que são dos tipos 07 e 08 têm o campo preenchidos com zero. Em testes mesmo definindo para nunca enviar o NCM nestes registros do bloco C o arquivo gera com esses zeros no campo. Desde já, grato pela atenção.

Boa tarde Francesco, somente se precisar!

Bom dia Gilson, tudo bem!? Gerei um novo XML com os campos de contribuinte e fisco e ambos foram para o XML, não se repetiu o comportamento que mencionou, porém, ainda tenho retorno de falha de Schema, se importaria de compartilhar seu XML autorizado?

Com a NT2021.004 onde criaram os campos Observações de uso livre do Fisco e do Contribuinte, alguém teve problemas com transmissão de notas tendo esses campos preenchidos? Estou recebendo "Rejeição: Falha no Schema XML do lote de NFe". Atualizamos os schemas, e conforme o leiaute mais recente o elemento para receber essas informações é o 'Obsitem' no elemento 'det'. Após implementação geramos o XML (em anexo) com os campos ObsCont preenchidos, porém retornando a rejeição na transmissão. Têm a informação se estes campos estão ativos no Webservice para recebimento dessas transmissões? ou alguma dica do que pode estar gerando a falha, desde já agradecido. NFE31220410579567000118550010000340031742885127-nfe.xml