Ir para conteúdo
  • Cadastre-se

tobexy

Membros
  • Total de ítens

    41
  • Registro em

  • Última visita

Tudo que tobexy postou

  1. Se não for alterado nada e manter o INI com o ; como quebra, acontece isso: O envio monta o xml certo (anexo: 1-env-lot.xml). Se acessar o site e baixar o xml fica certo (anexo: ISSNET.xml). Porém o retorno do componente vem sem as quebras (anexo: 0-lista-nfse.xml). Esse retorno é pego do "ACBrNFSe.NotasFiscais.Items[0].XMLNFSe". Inclusive se notar o nome da empresa que tem um & também fica errado. 0-lista-nfse.xml 1-env-lot.xml ISSNET.xml
  2. Da forma como ele está hoje se eu mudar no arquivo INI para qualquer coisa, exemplo || ele está ficando assim: "Mensalidade do sistema ERP &lt||br&gt|| Implantação do sistema ERP" quando o certo deveria ser "Mensalidade do sistema ERP <br> Implantação do sistema ERP"
  3. Olá Italo, pelo fato desse servidor aceitar <br> como quebra de linha, porém se mandar isso da erro então o componente já altera ele para &lt;br&gt; Então quando mando no campo Discriminacao o valor "Mensalidade do sistema ERP <br> Implantação do sistema ERP", quando chega nesse trecho do código ele está "Mensalidade do sistema ERP &lt;br&gt; Implantação do sistema ERP". Até aqui tudo bem, ele envia o XML assim e se consultar no site ele está certo, o problema está quando pego o retorno desse XML em ACBrNFSe.NotasFiscais.Items[0].XMLNFSe esse arquivo está sem esses caracteres, por isso vi que alterando ali fica tudo certo.
  4. tobexy

    Quebra de linha com ISSNET

    Olá, estou tendo problemas com a quebra de linha ao tentar enviar uma NFSe em Cascavel/PR que utiliza o ISSNET, o problema se dá que nesse servidor a quebra de linha é assim: <br> logo, quando é montado o xml fica assim: &lt;br&gt; com isso, vi que no arquivo "..\\ACBr\Fontes\ACBrDFe\ACBrNFSe\PCNNFSe\pnfsNFSeW_ABRASFv1.pas" nas linhas 358/359 e 419/420 tem respectivamente as seguintes instruções: Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1, StringReplace(FNFSe.Servico.Discriminacao, ';', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR); Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1, StringReplace( NFSe.Servico.ItemServico[i].Discriminacao, ';', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR); então, para que eu coloque como quebra de linha por exemplo o "||" além de mudar o arquivo ISSNet.ini precisaria mudar essas 4 linhas para que ele reconheça os caracteres de quebra. Sugestão seria isso: Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1, StringReplace(FNFSe.Servico.Discriminacao, '&lt;br&gt;', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR); Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1, StringReplace( NFSe.Servico.ItemServico[i].Discriminacao, '&lt;br&gt;', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR); segue em anexo o arquivo alterado com a sugestão acima pnfsNFSeW_ABRASFv1.pas Ou teria outra solução?
  5. Vejo que temos 2 problemas nessa rotina, um é o tempo de cancelamento caso a empresa fique sem internet, porém o principal é que a receita deixa bem claro "uma das exigências legais é que o cancelamento ocorra antes da ocorrência do fato gerador". Ou seja, cancelar uma nota depois que a venda já aconteceu (cliente já levou o produto) é errado e pode dar dores de cabeça
  6. Pessoal, alguma ajuda por favor?
  7. tobexy

    Erro nos acentos do XML da NFe

    Bom dia pessoal! Estamos nos deparando com um problema na geração do XML para NFe com acentuação, o método "ACBrNFe.NotasFiscais.GravarXML()" grava o arquivo na pasta teoricamente sem problema, porém ao fazer um "TStringList.LoadFromFile" pelo Delphi XE2 os caracteres com acentos vem com problema, exemplo, o caracter í vem Ã-. O mesmo acontece quando damos um "ShowMessage()" usando o método "ACBrNFe.NotasFiscais.Items[0].XML". Ou seja, não é uma situação que acontece apenas no debug do Delphi. Vimos no tópico Link que foi falado sobre isso porém para resolver outra coisa, mas assim como lá, aqui a situação acontece na unit ACBrUtil, método "NativeStringToUTF8" é chamado o "SetCodePage(RBS, 0, False)" e nesse momento que é alterado. A título de curiosidade, notamos que ao abrir o XML pelo Notepad++ a formatação está em "UTF-8 (sem BOM)" se converter para "UTF-8" e salvar, o arquivo passa a carregar certo no Delphi e mostra corretamente no "ShowMessage()". Outra coisa que percebemos é que se circundar o método dessa forma "Utf8ToAnsi(ACBrNFe.NotasFiscais.Items[0].XML)" passa a retornar corretamente. Lembrando, esse problema só acontece olhando para todo o arquivo XML nos 2 métodos acima mencionados, se tentarmos pegar o resultado, por exemplo, "ACBrNFe.NotasFiscais.Items[0].nfe.cobr.dup.items[0].ndup" a situação não acontece, é retornada a palavra acentuada corretamente. Para simular no exemplo em "..\ACBr\Exemplos\ACBrDFe\ACBrNFe\Delphi", colocarmos no botão “Importar TXT/XML” dois "ShowMessage()" antes da linha 1357, conforme a imagem em anexo: ShowMessage(ACBrNFe1.NotasFiscais.Items[0].XML); ShowMessage(Utf8ToAnsi(ACBrNFe1.NotasFiscais.Items[0].XML)); E o resultado conforme descrevi estão tbm em imagem em anexo, além do arquivo XML. Nossa dúvida é, vamos ter que fazer isso, colocar Utf8ToAnsi(), em todo lugar ou existe outra forma de pegar o XML inteiro do componente acentuado corretamente? 41170111434649000137550010000903371000903371-nfe.xml
  8. Boa tarde pessoal! Existe uma forma de inserir manualmente o bloco de autorização de uso em um XML, sem usar o webservice de consulta? Eu sei que passando o XML na consulta ao webservice o componente faz isso, porém estou tendo problema com queda de internet em alguns clientes, o que resulta em 2 XMLs diferentes para a mesma nota, o primeiro é o que foi e está na receita e o segundo é o atual, na consulta uso o atual sem assinatura e tenho o componente me retorna o protNFe que tem o digestvalue, com o digestvalue sei exatamente qual o XML que está na receita, com isso atualizo a nota pra o XML correto e para não fazer uma nova consulta, que vai consumir recurso do webservice, queria manualmente inserir a autorização de uso nele, pois já sei que ele é o correto. Então a dúvida é, existe alguma forma, sem usar o webservice de passar o XML assinado, passar o bloco protNFe e retornar o XML pronto?
  9. Bom dia. Situação testada e funcionando. Obrigado @Isaque Pinheiro, @Juliomar Marchetti e @Daniel Simoes
  10. Arquivo alterado pcnNFeR.pas
  11. Para corrigir aqui mudei a linha de: VersaoInfNFe := Leitor.rAtributo('versao='); para VersaoInfNFe := Leitor.rAtributo('" versao=');
  12. Olá pessoal! Identifiquei a situação, ela acontece em “pcnNFeR”, no método LerXml na linha 137 ele tem a seguinte instrução: NFe.infNFe.Versao := StringToFloat(VersaoInfNFe); Porém como disse antes esse XML da SEFA-PR tem uma tag a mais no início “<NFeLog versao="1.00">” Por causa dessa tag o valor retornado para “NFe.infNFe.Versao” está sendo 1 quando deveria ser 3,1, com isso ele entra errado na linha 152: if NFe.infNFe.Versao >= 3 then begin (*B09*) NFe.ide.dEmi := Leitor.rCampo(tcDatHor, 'dhEmi'); (*B10*) NFe.ide.dSaiEnt := Leitor.rCampo(tcDatHor, 'dhSaiEnt'); end else begin (*B09*) NFe.ide.dEmi := Leitor.rCampo(tcDat, 'dEmi'); (*B10*) NFe.ide.dSaiEnt := Leitor.rCampo(tcDat, 'dSaiEnt'); (*B10a*)NFe.ide.hSaiEnt := Leitor.rCampo(tcHor, 'hSaiEnt'); end; Resumindo, por causa da tag a mais, inserida no PR, ele pega a versão errada e consequentemente tenta pegar as tags de emissão e saída das versões antigas do XML quando deveria pegar das novas.
  13. Olá pessoal! Estou tendo um problema ao utilizar o recurso de importar XML no Delphi 7. Ao utilizar o método “LoadFromFile” em “ACBrNFeNotasFiscais”: Fdm_Principal.ACBrNFePrincipal.NotasFiscais.LoadFromFile(dirXml); Quando eu tento pegar a data de saída e data de emissão, é retornado o valor “zero”: Fdm_Principal.ACBrNFePrincipal.NotasFiscais.Items[0].NFe.Ide.dEmi; Mas tem um porém, se eu baixar o XML do servidor nacional da SEFA ou se eu pegar o XML que foi gerado pelo sistema usando o ACBr a falha não acontece. O problema só acontece se eu pegar o XML da SEFA-PR no novo recurso que eles disponibilizaram de baixar os XML em lote. Comparando os arquivos, vi que o XML da SEFA-PR tem uma tag a mais no início do arquivo “<NFeLog versao="1.00">”. Se eu editar o XML removendo essa tag, o arquivo importa com a data certa. Existe alguma forma de corrigir isso para que não precise editar o XML? Segue o XML das SEFAs para comparação, desde já obrigado. SEFA-Nacional.xml SEFA-PR.xml
  14. Olá pessoal! Desculpem resgatar a situação. Porém essa alteração está gerando problemas no pedido de cancelamento de NFe no Acre Identificamos que enquanto o sistema usava uma revisão antiga do ACBr no SVN (7400) tudo funcionava normalmente, porém com a atualização da revisão 7441 onde foi alterado o ../Fontes/PCN2/pcnAuxiliar.pas devido a esse erro que o Daniel postou, o sistema passou a gerar erro ao tentar cancelar uma NFe, vasculhando descobrimos que o erro é exatamente por causa dessa alteração, eu desfiz essa alteração postada pelo Daniel e o cancelamento voltou a funcionar normalmente, ou seja, atualizei todo o ACBr para a revisão de hoje (7790) e voltei o pcnAuxiliar.pas para ficar sem essa alteração postada aqui, com isso o sistema voltou a cancelar normalmente sem gerar erro. O erro que estava sendo gerado era esse: Falha na validação dos dados do Envio de Evento '2014-11-12T12:13:56-05:00' violates pattern constraint of '(((20(([02468][048])|([13579][26]))-02-29))|(20[0-9][0-9])-((((0[1-9])|(1[0-2]))-((0[1-9])|(1\d)|(2[0-8])))|((((0[13578])|(1...'. The element '{http://www.portalfiscal.inf.br/nfe}dhEvento'with value '2014-11-12T12:13:56-05:00' failed to parse. Categoria: EACBrNFeException Existe uma forma de conciliar as duas situações, implementando essa correção postada aqui sem impactar no cancelamento de NFe? Pelo que vi o problema parece ser nos schemas que estão validando de 0-4 no fuso, aí quando tenta colocar 5 dá erro, porém para não alterar os schemas modifiquei o pcnAuxiliar Obs.: Usamos a NFe 2.00
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.