windsoft

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.

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.

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.

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

Olá Italo, da forma que está ficou pior, nem o arquivo XML é salvo corretamente na pasta.

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.

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.

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

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

Olá @Italo Giurizzato Junior Infelizmente o problema persiste, esta da mesma forma que antes. Segue um XML de exemplo 4543.xml

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

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

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

Desculpe a pergunta ignorante. Mas não seria só verificar como estava na versão antiga? Pois não acontecia antes.

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

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

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

Usando as configurações recomendadas acima, funcionou adequadamente com OpenSSL

Olá, consegui identificar o problema lendo os fontes. Me corrijam se eu estiver errado, por favor. Agora ao invés de olhar para a propriedade NFSe.Status deve-se olhar para a propriedade NFSe.SituacaoNFSe = snCancelado para saber se a NFSe está cancelada. Se eu estiver correto, não seria melhor então remover a propriedade NFSe.Status pra evitar problemas?

Olá Bom dia! Ao consultar uma NFSe por RPS, utilizando o novo componente ACBrNFSeX, o componente não está identificando o status da nota adequadamente no provedor Ginfes. A consulta retorna as tags de cancelamento porém, no componente, a propriedade NFSe.Status continua igual srNormal, quando deveria estar como srCancelada Atenciosamente,

Olá bom dia! Realmente o cancelamento está funcionando agora, mas ao consultar a NFSe cancelada o status dela vem como srNormal. Vou abrir um novo topico.