Jump to content

windsoft

Membros Pro
  • Posts

    372
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by windsoft

  1. Olá bom dia! Desculpe pela demora, segue o XML do lote da guia. Atencisoamente,
  2. Olá @Italo Giurizzato Junior Não conseguiram nenhuma solução para o problema ainda?
  3. Olá Amigos boa tarde Percebi um pequeno problema na impressão do GNRe (FastReport), não sei se impacta na impressão do Fortes também, mas acredito que sim. Na leitura do XML o componente não estava preenchendo o campo TipoDocumento para o destinatário, e isso fazia com que não fosse impresso o CNPJ na Guia. Segue anexo o arquivo contendo a correção. Peço por favor que disponibilizem a todos. Segue também um arquivo XML de uma GNRE que pode ser usado pra testes antes e depois da correção. ACBrGNREGuiasRetorno.pas
  4. Sinceramente, nunca tentei enviar cobrança sem fazer o cálculo do dígito do nosso número. Vou ver se consigo fazer este teste de alguma forma e retorno com mais informações, caso consiga.
  5. Não, acho que você está enganado, são 9 posições já com o DV incluso. Ou seja, o nosso número tem 8 posições + o DV
  6. Boa tarde! Você tem que olhar apenas para o manual do Safra Livre, pois o Safra Bradesco está implementado em outra unit do ACBr (AcbrSafraBradesco) e o Safra Itau sequer está implementado.
  7. Sim concordo, é exatamente o que está acontecendo conosco após a atualização, os boletos emitidos antes não tinham o dígito, agora tem.
  8. Se eu utilizar da forma que esta eu tenho que salvar o nosso numero ja com o digito verificador, diferente do que acontece nos demais bancos. Não há recusa na remessa só a lógica está errada. Pois antes usava a mesma logica e agora não. Com isso os boletos que foram emitidos antes, estao sem o dígito verificador no meu banco de dados, e se eu imprimo uma segunda via do boleto, por exemplo, fica errado. Eu uso a sequencia de nosso numero livre. Antigamente usava a sequencia pre-definida, mas depois que os boletos passaram a ser pagos, mesmo vencidos em qualquer banco, o banco Safra passou a emitir boletos próprios e com a sequencia livre. Acho dificil quem ainda utilize os demais, pois o próprio banco desencoraja isso porque o banco utilizava bancos correspondentes como Bradesco e Itau. Enfim, como eu disse, da forma que está não está errado, o problema que vejo é justamente a falta de padrão, já que nos demais bancos não se inclui o dígito verificador no nosso número.
  9. Olá @José M. S. Junior, nós já utilizamos este banco a bastante tempo. Mas mantemos uma cópia dos fontes personalizada para não termos que fazer um tratamento especial na geração dos boletos e na geração do arquivo de remessa. Se vocês acham melhor deixar assim, tudo bem.
  10. Olá Panda não vejo como peculiaridade. o resultado do arquivo é o mesmo. A diferença é que nos demais bancos o ACBr está calculando o dígito do nosso número no momento da geração do arquivo, como no ajuste que eu fiz. Da forma que está quem for implementar tem que fazer regra diferente entre um banco e outro pra tratar o nosso número. Isso poderia ser evitado simplesmente com este ajuste.
  11. Bom dia A minha sugestão não se refere à incompatibilidade com o manual do banco, mas em "falta de padrão", pois nos demais bancos implementados no ACBr, o campo nosso número é informado sem o dígito e o dígito é calculado pelo componente, tanto na emissão de boletos quanto na geração de arquivos de remessa. Só sugeri que seja ajustado para que sigam o mesmo padrão.
  12. Olá Amigos boa tarde! Gostaria de sugerir a correção na geração de arquivos de remessa e emissão de boletos para o banco SAFRA. Seguindo o padrão dos demais bancos já implementados, o campo nosso número não deve conter o dígito verificador, ele deve ser calculado durante a emissão do boleto e/ou remessa. ACBrBancoSafra.pas
  13. Olá Italo, da forma que está ficou pior, nem o arquivo XML é salvo corretamente na pasta.
  14. Bom dia, resolvi temporariamente a questão fazendo uma gambiarra e lendo o arquivo da NFSe que o ACBr gera, se ler a propriedade XML do componente, como eu já disse, continua incorreto. Pelo menos conseguimos sanar o problema para o cliente até sair uma solução definitiva.
  15. Olá bom dia! Atualizando a informação: Com estas alterações acima, o arquivo XML é salvo na pasta de maneira adequada, mas quando leio o arquivo da propriedade ACBrNFSe1.NotasFiscais.Items[i].XML ele está com o mesmo problema, então me parece que a correção está funcionando, porém falta fazer mais algo pra que o XML que é informado na propriedade XML esteja com o mesmo conteudo do arquivo.
  16. Olá @Italo Giurizzato Junior boa noite. Estudei um pouco mais os fontes mas ainda não consegui compreender o problema. Talvez te ajude, eu fiz um teste aqui descomentando algumas linhas que estavam comentadas. No Ponto (1) o FPRetorno fica com a acentuação correta, no Ponto (2) volta a ficar incorreta. Segue anexo os 2 arquivos de resultado if ((Pos('application/xml', CharSet) > 0) or (Pos('text/xml', CharSet) > 0)) and (Pos('utf-8', CharSet) > 0) then FPRetorno := UTF8ToNativeString(ReadStrFromStream(HttpClient.DataResp, HttpClient.DataResp.Size)) // Aqui a acentuação fica correta else FPRetorno := string(ReadStrFromStream(HttpClient.DataResp, HttpClient.DataResp.Size)); // FPRetorno := string(ReadStrFromStream(HttpClient.DataResp, HttpClient.DataResp.Size)); FPRetorno := RemoverDeclaracaoXML(FPRetorno); FPRetorno := StrToXml(FPRetorno); case TipoEncoding(FPRetorno) of teUTF8: FPRetorno := UTF8ToNativeString(AnsiString(FPRetorno)); teISO8859_1: FPRetorno := string(TranslateString(AnsiString(FPRetorno), 0, 28591)); teUNICOD: begin FPRetorno := FaststringReplace(FPRetorno, '&', '&', [rfReplaceAll]); FPRetorno := ConverterUnicode(FPRetorno); end else end; // Alsuns provedores retorna uma string apenas com a mensagem de erro if Pos('Body', FPRetorno) = 0 then FPRetorno := GetSoapBody(FPRetorno); // Alguns provedores não retornam o XML em UTF-8 FPRetorno := ConverteXMLtoUTF8(FPRetorno); // Aqui volta a ficar incorreta PFRetorno (2).txt PFRetorno (1).txt
  17. Olá @Italo Giurizzato Junior Estou tentando encontrar o problema, os 2 pontos que você pediu estão aqui, veja se te dá alguma pista. PFRetorno (1).txt PFRetorno (2).txt
  18. Olá @Italo Giurizzato Junior Infelizmente o problema persiste, esta da mesma forma que antes. Segue um XML de exemplo 4543.xml
  19. Olá Amigos, encontrei o problema. A função Clear do objet TGNRERecibo estava limpando o número do recibo. Como ela é chamada por herança no InicializarServico do TDFeWebService, o número do recibo era sempre passado em branco na consulta do lote. Segue a Unit corrigida. ACBrGNREWebServices.pas
  20. Pessoal, estou com os fontes atualizados mas pra mim continua acontecendo o mesmo problema. "O valor do campo 'numeroRecibo' está inválido. O valor deve possuir 10 caracteres numéricos" Testei utilizando o DEMO do ACBRGNRe
  21. Olá @Victor H. Gonzales - Panda, bom dia! Precisa apenas da correção no código da mora, no seu arquivo você está olhando para o código da multa. Nos demais ajustes está tudo ok. Ajustei aqui, segue o arquivo ajustado. ACBrBancoInter.pas
  22. Desculpe a pergunta ignorante. Mas não seria só verificar como estava na versão antiga? Pois não acontecia antes.
  23. Olá Amigos, conforme solicitado, estou abrindo este ticket para verificação do problema na impressão de caracteres inválidos nos dados do prestador do serviço. Segue XML e PDF de exemplo. 3522010803285800014056000000000003050-nfse.pdf 3522010803285800014056000000000003050-rps.xml
  24. Segue uma novas correções no arquivo de remessa do banco Inter. Ao informar o código de mora diferente, deve ser informado o valor de mora em local diferente. O campo "SeuNumero" que é de uso livre da empresa, não estava sendo enviado. Há um erro no manual também que diz que o campo deve ser preenchido com zeros se não informado, porém o campo é alfanumérico e, assim como nas demais instituições financeiras, é de uso livre da empresa. ACBrBancoInter.pas
  25. Olá Amigos, segue anexo a correção para informação adequada do código de mora/juros no banco Inter. O código estava fixo na geração da remessa como "2" que, segundo o manual, é percentual. Implementei os 3 códigos possíveis conforme descrito no manual. 160 a 160 Campo de juros/ mora 001 Se = 0, sem juros/mora Se = 1, valor fixo de juros/mora Se = 2, percentual de juros/mora Segue anexo o manual, bem como a unit ajustada. Manual_CNAB_400_Inter.pdf ACBrBancoInter.pas
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.