flaviageisler

Bom dia! Fiz o teste de emissão de NFCe agora mesmo, consultei o QR Code e o site mostrou as informações da nota corretamente. Acredito que fizeram a correção nessa manutenção que o Anderson citou. Até os QR Codes das notas emitidas semana passada abriram corretamente. Obrigada a todos pela atenção, acredito que o tópico possa ser fechado. Att,

Bom dia, A resposta da CAF foi a seguinte, "Não há relatos de problema semelhante. O plantão fiscal não tem condições de analisar arquivos XML.".

Sim, somente temos gerado o CSC de homologação para esse cliente. Caso o CSC não fosse o correto a nota não seria autorizada e voltaria a rejeição 464 - Rejeicao: Codigo de Hash no QR-Code difere do calculado. Att,

Olá! Estão sim! Fiz a atualização do repositório e rodei o instalador e continua a mesma coisa. A nota autoriza normalmente. Ao ler o QR Code o site mostra mensagem de inválido. INI: URL-QRCode=https://hom.sat.sef.sc.gov.br/nfce/consulta?p= XML: <qrCode>https://hom.sat.sef.sc.gov.br/nfce/consulta?p=42210327766902000190650010000000141234368473|2|2|1|17F0C93BAD3D23C5A5EE9E6A5186886583E9E6EB</qrCode> <urlChave>https://hom.sat.sef.sc.gov.br/nfce/consulta</urlChave> Irei abrir um chamado na CAF de SC sobre a situação. Assim que eles responderem eu dou um retorno aqui. Obrigada.

Olá! Estou fazendo a emissão de NFC-e para Santa Catarina, as notas estão sendo emitidas corretamente. Consulto a chave de acesso no link https://hom.sat.sef.sc.gov.br/nfce/consulta e todas as informações estão corretas. Ai fui testar o link do QR Code e o site mostra o erro "999-QR Code inválido". Verifiquei todas as informações que compõem o QR Code e elas estão corretas. Gostaria saber se mais alguém está passando por esse problema? Se o problema é só comigo ou talvez do site de SC? Obs: Fiz testes com QR Codes do PR e do RS e os mesmos estão abrindo corretamente. Att,

Olá! Estou com um problema ao importar xml de NFe de um fornecedor específico. Eles geram o xml da NFe todo identado e a TAG "protNFe" vem quebrada com enter conforme imagem abaixo. Isso faz com que o pcnLeitor não consiga encontra a TAG. Como eu não posso pedir ao cliente que fique abrindo o arquivo do xml e remova o enter, e o fornecedor se recusa a mexer no formato do arquivo que eles geram, eu fiz a seguinte alteração no rExtrai do TLeitor, adicionei um novo IF verificando somente a tagInicio. Segue em anexo arquivo alterado e o xml com o problema. Não sei se é a forma correta de validar essa situação específica. Desde já agradeço. Att. NFe41210175655720000194550010004984191100837796.xml pcnLeitor.pas

Fiz update, testei a alteração e está funcionando corretamente. Muito obrigada. Att.

Olá! Após realizar update no projeto do ACBr, ao finalizar minha aplicação, na qual faço a emissão de NFCe, está ocorrendo access violation. O break me leva end da unit ACBrLibXml2. Depois de realizar vários testes, se a ordem da chamadas na procedure LibXmlShutDown forem alternados, faz a liberação correta e não ocorre erro. Com erro Sem erro Segue em anexo a unit com a alteração. Se puderem analisar se realmente essa é a solução correta. Desde já agradeço. Att. ACBrLibXml2.pas

Olá! Fiz update, testei a alteração e está funcionando corretamente. Muito obrigada @Juliana Tamizou e @Italo Jurisato Junior. Att,

Olá! Quando o campo possuí duas casas decimais e informa 0,001 ele fica como R$ 0,00, mas com as alíquotas que possuem quatro casas decimais não funciona, veja os prints do teste abaixo. E com todo o respeito, mas é gambiarra, pois é necessário ficar verificando se o valor está ou não zerado e caso esteja, informar o valor 0,001. Atenciosamente, Flávia

Olá! Estou abrindo um novo chamado sobre a Rejeição 929 - Informado CST de diferimento sem as informações de diferimento na SEFAZ-PR, pois o chamado aberto é do SAC e não consigo adicionar resposta. O @Italo Jurisato Junior citou no chamado: "Você deve atribuir o valor de tal forma que a sua nota seja autorizada. Sim, você deve entrar em contato com a SEFAZ-PR e informa-los que no manual a tag é opcional, logo se o valor dela for zero não precisa ser gerada. E pede para eles se justificarem sobre a presença no XML dessa tag opcional mesmo com o valor zero, para que a nota seja autorizada." O que justifica a presença dessas TAGS OPCIONAIS no XML é a validação adicionada na NT 2019.001 v1.10. As tags são opcionais pois a implementação fica a critério da UF, mas como o Paraná implementou elas se tornam obrigatórias mesmo estando zeradas. Eu entendo que é uma situação chata onde a SEFAZ-PR está se contradizendo quanto ao que é imposto pelas regras da documentação da NFe, mas também é incorreto informar valor "0,01" ou "0,0001" nas tags para que a nota seja autorizada. Creio que a melhor opção para o problema seria a criação de uma propriedade semelhante a "ACBrNFe.Configuracoes.Geral.CamposFatObrigatorios", para que notas enviadas a SEFAZ-PR contenham as TAGS mesmo zeradas. Para conseguir fazer a emissão normal da NFe fiz uma alteração na unit pcnNFeW.pas, colocando como Ocorrência 1 as tags do CST51. Gostaria que se possível essa adequações entrasse no commit do ACBR. Atenciosamente, Flávia.

Olá! Gostaria apenas de acrescentar uma situação pela qual passamos com a ConsultaCadastro. Em máquinas com Win7 com ou sem SP1 estava ocorrendo o erro: "Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor". Descobrimos que era problema com o TLS 1.2 que não estava funcionando corretamente. Então foi necessário instalar as atualizações abaixo. - Instalar o SP1(Nas máquinas que ainda não a possuem) (https://www.microsoft.com/pt-BR/download/details.aspx?id=5842) - MicrosoftEasyFix51044 (http://download.microsoft.com/download/0/6/5/0658B1A7-6D2E-474F-BC2C-D69E5B9E9A68/MicrosoftEasyFix51044.msi) - KB2992611 (https://www.microsoft.com/pt-br/download/details.aspx?id=44633) Após instalar todas as atualizações o erro não aconteceu mais e a consulta funcionou perfeitamente.

ES não. Não funciona para as UFs AC, AL, AP, DF, ES, PB, PI, RJ, RN, RO, RR, SC, SE, TO. Mas adicionando LT_TLSv1_2 funcionou corretamente para os outros em que a consulta está disponível. Estou usando as configurações abaixo: NFe.Configuracoes.Geral.SSLLib := libWinCrypt; NFe.Configuracoes.Geral.ModeloDF := moNFe; NFe.Configuracoes.Geral.FormaEmissao := teNormal; NFe.Configuracoes.Geral.VersaoDF := ve400; NFe.Configuracoes.Geral.Salvar := False; NFe.Configuracoes.WebServices.Ambiente := taProducao; NFe.Configuracoes.WebServices.SSLType := LT_TLSv1_2; NFe.Configuracoes.Certificados.ArquivoPFX := 'C:\Softniels\Onix\Certificado\Certificado Digital E-cnpj Unicomper_calisto09.pfx'; NFe.Configuracoes.Certificados.Senha := 'calisto09'; NFe.Configuracoes.Arquivos.PathSchemas := 'C:\Softniels\Onix\esquemas_xml\nfe'; Indico fazer os testes sempre em produção, pois em homologação a consulta não funciona em alguns estados.

Olá, Fiz a inclusão da linha e agora está funcionando corretamente. Muito obrigada pela ajuda. Torcer para que os outros estados liberem logo também os webservices.

Olá! Estou com os fontes atualizados sim. Creio que o problema sena na utilização da libWinCrypt ao invés de OpenSSL ou Capicom.