Jump to content

windsoft

Membros Pro
  • Posts

    372
  • Joined

  • Last visited

  • Days Won

    1

windsoft last won the day on February 18 2015

windsoft had the most liked content!

About windsoft

Contact Methods

  • Website URL
    http://www.windsoft.com.br

Recent Profile Visitors

2,098 profile views

windsoft's Achievements

  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.
×
×
  • 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.