-
Total de ítens
11 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Tudo que Gustavohq postou
-
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!
-
Envio de TAG CRT - NT 2022.001
Gustavohq replied to Carlos Lopes (Carlos Violeiro)'s tópico in ACBrCTe
Obrigado pelo retorno Nilton, também deixei pronto, aguardar a obrigatoriedade agora!! -
Envio de TAG CRT - NT 2022.001
Gustavohq replied to Carlos Lopes (Carlos Violeiro)'s tópico in ACBrCTe
Quase um mês depois e ainda não consegui enviar em MG, alguém já conseguiu enviar essa tag que possa me ajudar? -
Envio de NCM vazio para os registros C180 e C190, sendo preenchido com zeros
um tópico no fórum postou Gustavohq ACBrSPEDPisCofins
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. -
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