windsoft

Me desculpe pela demora, segue o XML conforme solicitado. OBS: 1. Este é o XML gerado pela prefeitura 2. No arquivo .fr3 do modelo de impressão Ginfes mais recente, o valor de retenção de impostos federais está com o texto 0,00 fixo, não tem uma variável ou um campo associado a ele então acredito que não foi feita nenhuma correção em versões mais novas. 3.773596058588953E8.xml

Olá pessoal, bom dia! Observamos que na impressão padrão "DANFSEPadraoGinfes.fr3" as retenções de impostos federais não estão sendo totalizadas adequadamente. O campo "retenções federais" está com o valor 0,00 fixo na impressão. Ajustamos a impressão para que seja totalizado o valor dos impostos federais e estamos disponibilizando aqui para que seja disponibilizado para toda a comunidade. Esta imagem abaixo, é uma NF emitida diretamente pelo site do GINFES, veja que os impostos federais são todos totalizados no campo "Retenções federais" Esta outra imagem é da impressão "DANFSEPadraoGinfes.fr3", observe que os impostos são sempre totalizados como 0,00 DANFSEPadraoGinfes.fr3

Eu enfrento exatamente o mesmo problema já tem algum tempo. Aparentemente é cagada na SEFAZ mesmo. Eu acredito que não há o que fazer nestes casos.

Olá Amigos bom dia! Hoje me deparei com uma situação já discutida anteriormente aqui no forum. A possibilidade de geração de arquivos de remessa CNAB400 com 444 posições achei estranho mas o manual do banco SOFISA também pede que seja enviada a chave da NFe no CNAB400 fazendo com que o arquivo fique com 444 posições. Alguns outros bancos já fizeram esta solicitação de envio da chave, mas geralmente são mais coerentes e criam uma seção nova no arquivo de remessa ao invés de aumentar o tamanho do registro de transação, porém infelizmente este não é o caso do SOFISA. Eu fiz o ajuste aqui para que seja enviado o arquivo com 444 posições conforme pede o manual (Anexo), verifiquem a viabilidade de disponibilizar para os demais usuários. NOVO_CNAB444v2.pdf ACBrBancoSofisaSantander.pas

Olá bom dia! Obrigado por subir a correção. Agora é possível gerar boletos usando ISAPI conforme esperado.

Bom dia! Ao tentar gerar o PDF do Boleto com FortesReport em uma aplicação ISAPI, recebo o erro "Operation not supported on selected printer". Pesquisando sobre o assunto, percebi que o mesmo erro ocorria na geração de DANFe com FortesReport e foi solucionado apenas informando Numcopias = 0, porém ao observar o código SetNumCopias do ACBrBoleto ele, não só permite Numcopias maior que zero. Fiz o ajuste no código e consegui gerar boletos usando ISAPI sem problemas. Sugiro que o mesmo ajuste seja feito no ACBrBoleto Segue a unit ajustada para disponibilização aos demais usuários. ACBrBoleto.pas

Olá bom dia! Desculpe pela demora, segue o XML do lote da guia. Atencisoamente,

Olá @Italo Giurizzato Junior Não conseguiram nenhuma solução para o problema ainda?

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

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.

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

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.

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.

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.

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.