Vanessinha Mocellin

Italo, esse documento foi atualizado em abril, acho que por isso nosso desentendimento. Essas informações não constam mais no doc. Segue em anexo o doc atualizado baixado agora da SEFAZ. Manual_de_Especificacoes_Tecnicas_do_DANFE_NFC-e_QRCode_Versao3.2.pdf

Então Italo, segundo as especificações do documento disponibilizado pela SEFAZ não cita que o token de homologação deve ser gerado de forma diferente. Pelo menos não encontrei. Poderia me informar onde esta sendo evidenciado que o token de homologação deve ser os 8 primeiros digitos do CNPJ do emitente + 20 (fixo) + ano + 4 ultimos digitos do ID do token? Precisaria saber onde consta essa informação para argumentar com a SEFAZ. Obrigada

Boa tarde Italo, Já havia analisado esse doc, mas analisei novamente para verificar se tinha me passado em alguma coisa. Não encontrei nesse documento informações para geração do Token diferenciado em homologação, abaixo oque consta no documento referente ao token de homologação: Para a emissão de NFC-e em ambiente de homologação a empresa deverá utilizar CSC (token) que solicitou pela página web de sua Secretaria da Fazenda. Partindo desse principio, se entende que tanto em homologação como em produção pode ter um token válido, isso dependendo do estado. No estado do MT para realização de testes no ambiente de homologação, o token poderá ser gerado pelo próprio contribuinte, não sendo necessário solicitar junto a SEFAZ. Porém no RS em ambiente de homologação não valida um token gerado manualmente. Na função GetURLQRCode quando é homologação o token passado de parâmetro é IGNORADO e o mesmo é gerado através da chave e do IDToken, código abaixo: cTokenHom := Copy(AchNFe, 7, 8) + '20' + Copy(AchNFe, 3, 2) + Copy(cIdToken, 3, 4); A principio no MT então o token de homologação gerado pela função GetURLQRCode seria valido (não fiz os testes referente a esse estado para ter certeza). Acredito que se o ambiente for homologação e for passado de parâmetro o token, o mesmo deveria ser utilizado para geração do hash. Exemplo: if (( AAmbiente = taHomologacao ) and ( AToken = '' )) then sToken := cIdToken + cTokenHom else sToken := cIdToken + cTokenPro;

Bom dia j2c9m7 Conforme citei, com o token de produção funciona corretamente sim, já estou utilizando dessa forma. Apenas queria reportar essa situação aos membros da ACBr (pois seria um problema), onde o hash esta ficando inválido com o token de homologação para o RS, com os demais estados ainda não testei. Tentei gerar o hash de N formas, para tentar achar uma solução, porém não conseguir gerar um hash válido em homologação, por isso estou repassando o problema, para verificar se alguém teria a solução. Obrigado pela colaboração j2c9m7 Abraço

Boa tarde Srs. Estou enfrentando um problema ao consultar o QR-Code gerado pela ACBr. Erro SEFAZ: Msg: 411 - QR-Code Inválido (Hash do QR-Code) https://www.sefaz.rs.gov.br/NFCE/NFCE-COM.aspx?chNFe=43140590180621000197650020000000311000000312&nVersao=100&tpAmb=2&dhEmi=323031342D30352D32385431313A31353A33372D30333A3030&vNF=1.23&vICMS=0.21&digVal=6F463346574B4D4B754A2F6F3379387A64346D394E6146355A55343D&cIdToken=000001&cHashQRCode=1557066B8455C5B198DA0B8321B0C7113923BB27 Estou utilizando a nova função disponibilizada NotaUtil.GetURLQRCode. Em ambiente de produção o QR-Code é validado corretamente, essa situação ocorre apenas em ambiente de homologação (estado RS - ambiente virtual RS). Oque muda de produção para homologação é o token: Em produção é utilizado o próprio token passado de parâmetro. Em homologação é gerado um token. Fonte -> Copy(AchNFe, 7, 8) + '20' + Copy(AchNFe, 3, 2) + Copy(cIdToken, 3, 4); Alguém se deparou com essa mesma situação? Será que é problema na geração do token ou na SEFAZ? Obrigada.

Bom dia Estou tentando realizar a transmissão de uma NFE ( estado SC - Versão 3.01 ) de forma SINCRONA: ACBrNFe.Enviar( NumeroLote, False, True ); Ao executar a função TWebServices.Envia é realizado dois processos: 1 - envio do lote 2 - processa retorno ( se for moNFe OU se não for Sincrono ) No primeiro processo de envio do lote esta tudo OK, esta retornando cStat = 104, a nota esta sendo autorizada na SEFAZ corretamente. Em anexo XML de envio e de recebimento do lote ( nome do arquivo de recebimento esta incompleto devido a property FRecibo estar vazia ). Porém no segundo processo de retorno o lote não esta sendo encontrado cStat = 106, devido a consulta ser realizada pelo Recibo e o mesmo estar sem valor. Minha dúvida seria a seguinte, devemos realizar o processamento de retorno quando a transmissão for sincrona? 598-env-lot.xml -pro-rec.xml

Bom dia Italo. Fiz os testes e ficou OK Obrigado

Boa noite Estou realizando testes referente a NF-e .3.1 com item do tipo produto e item do tipo serviço na mesma nota, essa situação é bem recorrente em nossos clientes. Esta ocorrendo erro no campo dCompet (campo novo adicionado na versão 3.1), erro: dCompet' element is invalid - The value '20140116' is invalid according to its datatype Segundo o manual esse campo deve ser formato da seguinte forma AAAAMMDD, oque estaria certo (20140116). A mensagem de erro informa que o valor informado não seria uma data, fiz a alteração no XML para o formato AAAA-MM-DD (2014-01-16) e validou corretamente. Partindo do seguinte entendimento, o campos esta sendo formatado de acordo com o solicitado no manual ( tipo STRING ) porém ele é validado como DATA. Segue em anexo XML xml.xml

Boa tarde Italo. Desculpe a demora de manha não consegui realizar os testes devido a falta de comunicação com o WebService ( erro 999: Falha no processamento do WebService ). Testei agora e esta 100% Muito obrigado pela atenção Segue XML de retorno da consulta pelo recibo: <retConsReciNFe versao="2.00" xmlns="http://www.portalfiscal.inf.br/nfe"> <tpAmb>2</tpAmb> <verAplic>SVRS20140115093408</verAplic> <nRec>423000024404613</nRec> <cStat>104</cStat> <xMotivo>Lote processado</xMotivo> <cUF>42</cUF> <protNFe versao="2.00"> <infProt Id="ID342140000031194"> <tpAmb>2</tpAmb> <verAplic>SVRS20140115093408</verAplic> <chNFe>42140181342172000145550000000370061000370060</chNFe> <dhRecbto>2014-01-16T10:28:41</dhRecbto> <nProt>342140000031194</nProt> <digVal>rf0al7W8vND4GA7KKBu7vg+3Pl0=</digVal> <cStat>100</cStat> <xMotivo>Autorizado o uso da NF-e</xMotivo> </infProt> </protNFe> </retConsReciNFe>

Consegui autorizar sim Italo, segue em anexo os XML's gerados pelo componente. ProcNfe.rar

Nosso sistema ATUAL utiliza a versão 2.0 e todo o processo da nota fiscal eletrônica é feito de forma manual (trabalhamos apenas com NFe). Entre pesquisas, optamos por apostar na ACBr, em virtude das indicações. Estamos migrando ele para ACBr para justamente utilizar a nova versão 3.1, com todas as novas mudanças e exigências do fisco. No primeiro post desse tópico você menciona o seguinte: - Quando o modelo for moNFe, os valores aceitos pela propriedade VersaoDF são: ve200 e ve310. Porém se estiver configurado ve310, quando realizo a consulta da nota através do recibo ocorre o erro mencionado. Identifiquei que o erro ocorre por causa dessa propriedade pois quando esta com o valor default ve200 o erro não ocorre, conforme o Juliomar menciona. Utilizo SC, exemplo: ACBrNFe.Configuracoes.WebServices.UF := 'SC; Até onde sei SC não possui um servidor próprio, é utilizado o Sefaz Virtual do RS. Se consegui autorizar a NFe com a versão 3.01, não deveria conseguir consulta-la através de seu recibo?

Boa tarde Italo. Estamos migrando nosso servidor de nota fiscal eletronica para ACBr. Referente a parte de autorização fiz testes básicos e esta tudo ok. Porém ao executar a consulta do recibo esta ocorrendo o seguinte erro: Argument out of range Exemplo: ACBrNFe1.WebServices.Recibo.Recibo := iRecibo; ACBrNFe1.WebServices.Recibo.Executar; Verifiquei que o erro ocorre quando a property VersaoDF possui o valor ve310 Exemplo: ACBrNFe1.Configuracoes.Geral.VersaoDF := ve310; Esse erro pode ser simulado no Demo em questão, basta apenas setar essa property no evento onEnter, onde o ModeloDF esta sendo alimentado. Obs: Não sei se estou setando valor a VersaoDF corretamente, se ela deve ser setada apenas antes de enviar uma nota. A forma que estou utilizando é atribuindo valor a ela ao iniciar o programa, não alterando ela depois.