Leandro Vignoto

Verifica se nessa empresa tem o firewall SonicWall. Tive essa erro com esse firewall onde tem que liberar o IP de saída. Att. Leandro

Infelizmente não. O problema continua.

Já passei por situações onde a empresa utiliza o firewall sonicwall e era necessário liberação no mesmo. Att. Leandro

Ai ficou bom de saber como fazem sem o certificado digital.

Tenta validar esse xml em https://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx Att. Leandro

Bom dia. Normalmente... nenhum erro desde o dia 17 Att. Leandro

Atualizando o Acbr com as novas Url, resolve o problema. Att. Leandro

Bom Dia ! Para constar, acabei de emitir uma nota no MS em produção, com as URL antiga e por enquanto autorizou normalmente. Não atualizei as URL ainda por não saber se vai autorizar. Att. Leandro Vignoto

Bom dia. Para mim também esta dando rejeição no ambiente homologação de GO e MS sem o campo vDesc zerado no xml. No ambiente produção não testei ainda mas provavelmente vai dar a partir de 09/07. Att. Leandro

Bom Dia ! Ontem, em um ambiente de cliente, tentei vária vezes, com documentos diferentes efetuar a manifestação de ciência e confirmação da operação e obtive somente esse erro 12002. Att. Leandro

Boa Tarde ! Tenho a seguinte configuração no ACBR NF-e Está da seguinte forma no Acbr.inc Faço autorização de notas, cancelamentos, carta de correção, consulta situação, tudo funciona corretamente. Porém, ao registrar eventos de manifestação do destinatário (ciência, confirmação, etc) recebo o erro : Se eu registrar as dll da pasta "Capicom" esse erro é eliminado e o evento é registrado corretamente. Existe algum motivo para isso ? Da maneira que está, não deveria estar livre da capicom ? Att. Leandro

Não sei se é esses campos que estão no seu XML. Mas no MS, 4.0, homologação autorizou normal conforme imagem abaixo Att. Leandro

Por desencargo, acabei de fazer outra nota para o MS e autorizou corretamente. Onde acredito que deva ser a estrutura correta de XML sem a informação do grupo fatura. Também não tem problema da numeração da parcela, exigindo que seja sequencial. Então assim, se não estragarem, o MS está fazendo certo.... Att. Leandro 50180507648604000198550010000053321051822850-nfe.xml

No meu entendimento NÃO, pois na imagem do manual ele é opcional "0-1"; Além disso, no MS essa mesma estrutura de XML validou normal SEM O GRUPO FATURA, então não teria sentido ter regras diferente entre os estados. Mas, vai saber.... Att. Leandro

No Paraná hoje mudou a rejeição para 872 - Soma do valor das parcelas difere do Valor Liquido da Fatura. Na minha opinião ainda é erro da sefaz, pois essa consistência só deveria ocorrer se for informado o grupo de fatura que é OPCIONAL conforme o manual Provavelmente está consistindo valor das parcelas diferente do valor da fatura (que é zero pois não consta no xml) e está caindo na rejeição. Att. Leandro

Bom Dia ! Ao efetuar a distribuição DFe, no momento de decodificar o retorno de um resumo de documento, já apresenta os caracteres especiais de acentuação, conforme imagem abaixo: Com isso, o componente é carregado com essas informações incorretas, conforme imagem abaixo: Existes alguma forma de contornar/corrigir essa situação ? Att. Leandro Vignoto

Bom Dia ! Para informação, fiz os testes com os dados abaixo em ambiente de homologação MS - Autorizado normalmente PR - Rejeição 867 - Grupo duplicata informado e forma de pagamento não e Duplicata Mercantil, ou seja, ainda não está implementado pela sefaz Att, Leandro

Acredito não ser o caso, pois esse processo não envolve envio de e-mail, somente o registro do evento mesmo. Att. Leandro

Bom Dia ! Em várias situações, ao registrar um evento na NF-e (normalmente manifestações) apresenta o erro abaixo: Nesse caso era um evento de "Confirmação da Operação". Porém, ao solicitar novamente, apresenta o erro de "Duplicidade de Evento", ou seja, mesmo apresentando Timeout o evento foi registrado na base da Sefaz e com isso não consigo mais atualizar a base de dados pois não tenho mais informação do protocolo e como já discutido no forum não existe outro ponto para consultar a situação da manifestação e retornar os dados do evento. Ai que está a dúvida, pois no MOC diz que o registro de evento é "SÍNCRONO" então não deveria aguardar o retorno na mesma requisição ? Existe parametrização para evitar isso ? Qual o campo correto e um valor coerente ? Att. Leandro

Bom Dia ! Atualizei, testei e o problema foi resolvido. Obrigado. Att. Leandro

Não consegui simular a consulta posterior, pois é um serviço no windows e termino o processo no retorno da autorização....

Boa Tarde ! Ao executar os seguintes procedimentos, SEM REINICIAR O PROCESSO DE EMISSÃO DE NOTAS (entenda como aplicação) a) Faço a emissão de uma nota na versão 4.0 (não gera a tag "nfeCabecMsg") para NFeAutorizacao4 nem NFeRetAutorizacao4; b) Em tempo de execução, altero o componente para versão 3.10; c) Faço a emissão da nota na versão 3.10 (gera a tag "nfeCabecMsg" corretamente para NfeAutorizacao) e (não gera a tag "nfeCabecMsg" NfeRetAutorizacao3 incorreto ), com isso apresenta o erro "Cabecalho - Falha no Schema XML"; Parece bobeira isso, pois qual o sentido de mandar na versão 4 e depois na 3.10 ???? Em se tratando do sistema que disponibiliza para enviar em PRODUÇÃO e HOMOLOGAÇÃO ao mesmo tempo, a versão de produção está na 3.10 e a versão de homologação na 4.00, então ao enviar a nota em homologação a de produção para de funcionar. Depurei, mas não consegui corrigir. O problema está no ponto destacado abaixo, pois a variável FPHeaderElement vem vazia quando vai consultar o retorno da autorização realizada. XML CORRETO XML ERRADO Reforçando, o problema só ocorre no retorno da nota autorizada quando troca da versão 4.0 para 3.10 em tempo de execução. A nota da 3.10 é autorizada normalmente, somente o retorno apresenta problema. Com esses passos, talvez seja possível reproduzir em ambiente local. Att. Leandro

Boa Tarde ! Parece que saiu algo com relação a permitir a emissão de nf-e de produtor pessoa física http://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=tW+YMyk/50s= Nota Técnica 2018.001 - v 1.00 Att. Leandro

Boa Tarde ! Para informação