Rodrigo Sidney

O Ambiente de Homologação da NFC-e MG voltou a funcionar, Pode ser que seja intermitente o funcionamento mas agora a tarde no dia 29 esta funcionando. Quem tiver testes pra fazer aproveita antes que pare de novo Talvez essa seja "a primeira semana de dezembro/2021 " que avisaram na mensagem

Resposta da Sefaz de MG hoje as 14:00 pelo Fale Conosco: "Senhor(a), Conforme retorno da equipe de TI o ambiente de homologação está indisponível. Até a primeira semana de dezembro/2021 voltaremos com ambiente de homologação da NFC-e."

Sim, parece uma falha generalizada com os webservices de Homologação deles. Lembrando que o ambiente de homologação ficou uma semana fora do ar e voltou ontem a tarde com esse problema. Mandei mensagem pra Sefaz ontem perguntando se eles estão cientes do problema e me pediram pra enviar prints e xmls para que possam entender melhor. Espero que agora consigam corrigir. O estranho é que parece que eles não testam o proprio sistema antes de colocar no ar

Muito obrigado pela resposta. Concordo plenamente com você, perguntei aqui pra confirmar se não estavamos sendo muito rigorosos. Mas é exatamente esse o caminho. Temos o embasamento legal de como deve ser feito e vamos passar isso pra eles. Caso consigam um termo de ocorrência junto ao fisco pra não emitir a via do estabelecimento tudo bem, caso contrário segue a impressão automática. Obrigado a todos

Exatamente, é bem melhor impimir a segunda via do que ter que atender essas condições para fazer só a guarda do XML. O problema que enfretamos é que a Sefaz de Minas não conseguiu estabilizar os webservices da NFC-e até hoje e entra muito em contingência aumentando muito o gasto de papel. Temos clientes que reclamam muito e não entendem que a culpa não é nossa e apontam que existem comércios na cidade descumprindo essa obrigatoriedade. Então, no fim das contas, estamos pensando até em permitir que o usuário desative a impressão da segunda via e se responsabilize junto a fiscalização caso tenha algum problema deixando essa responsabilidade pra ele. (Para os que estão reclamando mais e deixando claro a responsabilidade deles) Já que existe essa possibilidade de obter a declaração para fazer apenas a guarda do xml e imprimir quando fiscalização vier, talvez o nosso sistema esteja assumindo a responsabilidade sem dar essa opção.

Obrigado pela resposta Juliomar, penso da mesma forma. É que em Minas Gerais estamos tendo muitos problemas com instabilidade da Sefaz então entra muito em contingência. Nossos clientes ficam reclamando de ter que imprimir a segunda via e sabemos que alguns comércios da cidade não imprimem a segunda via em contingência, apenas a via do cliente (De forma irregular). Por isso ficamos nessa encruzilhada entre deixar o sistema operando da forma correta de forma automática ou delegar a responsabilidade para o usuário. Para a ECF era mais simples porque o usuário não tinha opção, o sistema era homologado para operar seguindo 100% a legislação e não tinha choro Mas entendo a irritação deles porque a instabilidade dos Webservices da SEFAZ MG está uma novela interminável

O problema do Ambiente de Homologação foi resolvido. Era realmente um problema com a Sefaz de MG Entrando em contato com a Sefaz eles deram a seguinte resposta: "Conforme parecer da superintendência responsável, informamos que tivemos algumas ocorrências de instabilidade em nossos sistemas, e que os referidos problemas já foram sanados. Favor tentar novamente." Já em relação ao ambiente de Produção os problemas continuam e continua a mensagem de aviso no site do SPED MG : http://www.sped.fazenda.mg.gov.br/spedmg/nfce/ "O ambiente de autorização de NFC-e está apresentando instabilidade. O problema também está ocorrendo na funcionalidade de consulta de NFC-e. Estamos trabalhando para solucionar o problema o mais rápido possível."

Boa tarde pessoal, Essa dúvida não é em relação a implementação em si e sim sobre qual seria o comportamento mais correto nessa situação. Segundo o Manual do Danf-e da NFC-e a impressão do Danf-e pode ser dispensada em duas situações: "Ainda na hipótese contingência, deverá ser impressa uma segunda via do DANFE NFC-e que deverá permanecer a disposição do Fisco no estabelecimento até que tenha sido transmitida e autorizada a respectiva NFC-e emitida em contingência. Esta obrigação poderá, a critério da Unidade Federada, ser dispensada. Alternativamente à impressão da segunda via do DANFE NFC-e quando de emissão em contingência, o contribuinte poderá optar pela guarda eletrônica, em local seguro, do respectivo arquivo XML da NFC-e que deve possibilitar impressão do respectivo DANFE NFC-e para apresentação ao fisco quando solicitado." Então a dúvida é se o sistema deveria deixar essa decisão de imprimir ou não a segunda via da NFC-e em contingência a critério do usuário ou já fazer a impressão automática? Peço desculpas se essa pergunta estiver fora dos padrões do Fórum e pode ser removida mas é uma dúvida importante que tivemos e queria a opnião de vocês que vêem isso na prática todos os dias. Obrigado

Recebi o seguinte retorno da Sefaz de MG na quinta-feira, dia 26 sobre esse problema, mas a Sefaz ainda esta com problemas: "Senhores contribuintes, boa tarde! A STI já detectou o problema e está trabalhando na solução do mesmo. Orientamos aos contribuintes que, em caso de dificuldade na autorização do documento eletrônico, utilizem a contingência." Estava esperando que a Sefaz corrigisse o problema mas como estão demorando muito vou utilizar as alterações sugeridas pelo Ítalo. Aqui o problema ainda estava acontecendo na Inutilização de NFC-e, fiz uma alteração no arquivo do Ítalo para corrigir o retorno da Sefaz também para a função TNFeInutilizacao.TratarResposta ACBrNFeWebServices.pas

Também estamos com esse problema mas é um erro da Sefaz, eles tem que corrigir a mensagem de retorno. De acordo com eles a previsão para normalizar o serviço é hoje: "Informamos que o ambiente de emissão da NFC-e em modo normal encontra-se em manutenção corretiva, com previsão de retorno a partir de quinta-feira, dia 26/09. Neste período os contribuintes deverão emitir as NFC-e em modo de CONTINGÊNCIA OFF-LINE." Entrei em contato pelo "Fale Conosco" e eles disseram que essa previsão é tanto para o ambiente de homologação quanto o de produção

Estou com o mesmo problema, Ao cancelar uma NFC-e utilizando o cancelamento por substituição devido a problemas com time out, mando gerar novamente e uso a função Assinar porém ao tentar cancelar recebo um erro indicando que o DigestValue do documento não confere. Realmente o DigestValue gerado no xml é diferente do anterior. Consigo verificar isso simplesmente renomeando o xml de uma nota autorizada e gerando novamente já vem com DigestValue diferente.

Entendi, concordo com você Muito obrigado pela ajuda Felipe

Boa tarde Felipe, Isso parecia ser o mais correto mesmo, só fiquei na dúvida porque as documentações sempre fazem referencia a data de emissão e não achei nenhuma explicação mais detalhada. Mas nesse caso a data do movimento é que deveria ser mais importante mesmo. Utilizando a mesma data do movimento da redução Z para os Registros 60 m e para os Registros 60 d correspondentes o arquivo é aceito pelo validador sem rejeições. Muito obrigado

Pessoal, ao validar o Sintegra obtenho nas críticas do validador os avisos de que existem "Registros 60 diários sem o registro mestre correspondente" Isso só acontece em meses que existem cupons fiscais emitidos depois da meia noite e antes de tirar a redução Z do dia anterior Quando isso acontece a data de emissão que consta no registro 60 d fica diferente da data de emissão do registro 60 m que deveria ser o seu pai. Ex: 60M20181019BE0911101000112316810012D04566604567600225800400000000000882990000000235023452 60A20181019BE0911101000112316810560000000000000 60D20181019BE091110100011231681272 000000000100000000000000020240000000000000000F 0000000000000 60D20181020BE09111010001123168118 000000000100000000000000004400000000000000000F 0000000000000 A última linha do exemplo representa um item de cupom emitido depois da meia noite por isso tem data do dia 20 diferindo da data do Registro 60m pai que tem data do dia 19 e causando a mensagem de erro da validação já que ele não possui registro mestre correspondente A dúvida é como devo tratar a data de emissão dos Registros 60d relativos a cupons emitidos após a meia noite e antes de tirar a redução Z do dia anterior? Onde posso encontrar mais informações sobre a composição do Registro 60m?

A mesma que eu estava usando antes, foi a Sefaz que corrigiu lá, SSLCryptLib = cryWinCrypt SSLHttpLib = httpWinHttp SSLXmlSignLib = xsMsXml SSLType = LT_TLSv1_2

Pessoal, aqui voltou a funcionar. Agora esta transmitindo em homologação utilizando a forma de emissão normal ? Só que continua dando problema em contingência SVC-AN com Rejeição = 2999-Falha nao tratada.

As Sefaz continuam aceitando o protocolo SSL mesmo após a desativação do NF-e 3.10 tanto que sistemas como o Windows XP e Windows 7 desatualizado conseguem transmitir notas O problema é que depois que a Sefaz de Minas desativou o SSL em homologação começou a rejeitar a emissão das notas indicando "XML da area de dados codificado diferente de UTF-8" Essa rejeição não faz sentido, já verifiquei e não encontrei nada de errado

Estou tendo o mesmo problema ao transmitir NF-e Retorna a Rejeição: XML da area de dados codificado diferente de UTF-8 Ao tentar transmitir usando Contingência SVC-AN recebo a rejeição: 2999 - Falha não tratada Verificando o XML no validador da Sefaz do RS não indica nenhum problema no XML nem na validação dos Schemas Antes da Sefaz desativar o SSL funcionava normalmente

Aqui nos clientes com Windows XP foi só instalar as atualizações de segurança do Windows update também que voltou a funcionar

Entrei em contato com a Sefaz de MG ontem informando sobre o problema e me responderam o seguinte: De qualquer forma, mesmo que volte a funcionar normalmente, o Windows XP esta a cada dia mais ultrapassado e perdendo todo tipo de suporte e compatibilidade. Teremos que solicitar aos clientes que utilizem no mínimo o Windows 7

Também estamos tendo problemas ao consultar status de notas mas apenas em clientes que utilizam o Windows XP Esse problema esta acontecendo desde ontem de manhã. Para os clientes que utilizam o Windows 7 ou superior esta tudo funcionando normalmente. No site da Sefaz de MG eles divulgaram uma manutenção para o fim de semana passado, talvez tenham alterado algo que fez o sistema parar de funcionar no XP Link do aviso da Sefaz de MG: http://portalnfe.fazenda.mg.gov.br/ Postagem antiga aqui no fórum sobre um problema parecido:

Bom dia Obrigado Italo

Pessoal, esse é um tópico bem antigo mas só tivemos esse problema agora. Uma transportadora exigiu de um cliente nosso o Registro de Saída da NF-e aqui em Minas Gerais Existe algum componente do ACBr relacionado a esse registro de saída? Obrigado

Utilize o frceInstall.exe que esta na pasta trunk do Fortes Sobre o Fortes e como obter a versão correta veja esse post do Daniel : http://www.projetoacbr.com.br/forum/announcement/12-novo-fortes-report-ce-e-projeto-acbr/ Se tiver dúvidas ao instalar o ACBr veja esse tutorial publicado pelo Regys: https://regys.com.br/como-instalar-o-trunk2-do-acbr/

Crie um novo tópico e explique melhor seu problema. Mas para gerar a tag no xml basta informar o valor do campo. Ex: Prod.CEST := '1234567';