Ir para conteúdo
  • Cadastre-se

Juliana Tamizou

Administradores
  • Total de ítens

    14.860
  • Registro em

  • Última visita

  • Days Won

    188

Tudo que Juliana Tamizou postou

  1. Boa noite. Você configurou no ACBrMonitor o Diretório do arquivo? Att.
  2. Boa noite Wanderley. Fiz um merge das suas correções com outras que recebi recentemente e acredito que seu arquivo será gerado corretamente, existe apenas uma diferença com relação aos nomes de algumas variáveis,porém o conteúdo das mesmas é o mesmo. As alterações para este banco estão disponíveis no svn. Att.
  3. Boa noite. Foi adicionada ao svn uma alteração para que o nome do arquivo remessa seja calculado conforme orientação do manual do banco. Att.
  4. Boa noite. As alterações no ACBrBoleto estão disponíveis no svn. Att.
  5. Bom dia. O problema é que mesmo marcando apenas um titulo, todos são mostrados? ou os títulos estão se repetindo? Att.
  6. Bom dia Fabio. Você tem a unit alterada? se desejar anexe aqui pra que as alterações possam ser postadas no svn. Att.
  7. Bom dia. Você precisa primeiramente configurar om componente para o diretório onde os arquivos serão salvos, em seguida chamar a função LerRetorno() e efetuar a leitura dos titulos da listadeboletos verificando quais titulos devem ser baixados, etc... Att.
  8. Bom dia Fábio. Observe oque diz o manual do banco para convênios de 7 dígitos.. "O “Nosso-Número” do bloqueto deve estar de acordo com as normas estabelecidas pelo Banco do Brasil. FORMATO DO “NOSSO-NÚMERO” PARA CONVÊNIOS ACIMA DE 1.000.000 (UM MILHÃO): A composição do nosso-número deve obedecer as seguintes regras: CCCCCCCNNNNNNNNNN convênios com numeração acima de 1.000.000, onde: "C" - é o número do convênio fornecido pelo Banco (número fixo e não pode ser alterado) "N" - é um seqüencial atribuído pelo cliente O banco solicitou que o dígito do nosso número seja impresso neste caso também? Att.
  9. Bom dia. Basta alterar a propriedade Layout do componente de impressão para o layout desejado. Att.
  10. Bom dia Danilo. Comparando seu primeiro post ao último cheguei a conclusão que o header de arquivo e o header de lote estão corretos... Quanto ao aceite você informou ao componente a propriedade Aceite como Sim? para deixar como Não, basta setar essa propriedade corretamente em cada titulo. Att.
  11. Boa tarde Danilo. Efetuei um teste através do aplicativo demo do ACBrBoleto e todas as informações estão idênticas a orientação do banco. Você está com seu svn atualizado? Att.
  12. Boa tarde. O campo Subseqüências do registro (que você fixou o valor 01), não seria um contador de linhas de mensagem? Ou seja, se o boleto tiver apenas 1 linha de mensagem colocar 01 seria correto, porém se existirem 2 mensagens, não ficaria errado a Subsequencia do Registro ser 01 para as duas? Att.
  13. Boa tarde Maicon. Você conseguiu verificar com o banco qual o valor deve ser informado nada DataDesconto quando não o boleto não possui desconto? Quanto a posição 154 do segmento Q, este campo é referente ao Sacador/Avalista neste informamos 0 pois não utilizamos estas informações no boleto. O banco te disponibilizou outro manual contendo as orientações citadas nos seus posts? Att.
  14. Boa tarde Jeter. Implementei as correções que discutimos aqui, se possível efetue novos testes com os convênios de 10 posições que você utiliza. Att.
  15. Boa tarde. Efetuado modificação no componente para que o path para o arquivo gerado seja sempre informado no campo NomeArquivo, devido a não ser mais necessária foi removida a propriedade fDirArqPDF_HTML. Quando apenas o nome do arquivo é informado na propriedade NomeArquivo o próprio componente cálculo como diretório de destino a pasta da aplicação. Após efetuar a atualização e compilação dos componentes provavelmente ocorrerá um erro de compilação dos projetos que usam este componente, para resolver basta informar na propriedade NomeArquivo o path completo ou se desejar que seja gravado na mesma pasta do aplicativo, apenas o nome do arquivo.
  16. Bom dia. Observe oque diz o manual fornecido pelo banco 111 a 117 - Número Seqüencial de Remessa O número de remessa deve iniciar de 0000001 e incrementado de + 1 a cada novo Arquivo Remessa, com o objetivo de evitar que ocorra duplicidade de arquivo não podendo, em hipótese alguma, ser repetida ou zerada. Verifique junto ao banco se existe alguma alteração no manual que altere estas regras. Att.
  17. Bom dia Maicon. Qual padrão você está utilizando, SICOB ou SIGCB? Att.
  18. Bom dia. Foi postada esta semana uma correção para o Banrisul, efetue os testes novamente após baixar o svn. Att.
  19. Bom dia. A alteração por enquanto seria apenas no SICOB. Abaixo a explicação das diferenças de tamanho de nosso número livre, pensei em caso o nosso número informado contiver 10 ou 15 caracteres a formatação para incluir os valores fixos não seja aplicada e na função que citei antes definir o tamanho máximo baseado no que foi recebido. Carteira Sem Registro Com relação as possibilidades de tamanho para os nosso número de 10 posições é possível que exista o caractere fixo "9" ou "82" neste casos as posições livres são 9 e 8 respectivamente...para a de 15 posições o primeiro caractere fixo é 8, ou seja sobram 14 posições. Carteira Registrada Possui 10 posições porém o primeiro caractere também é fixo "9", fazendo com que sobrem apenas 9 dígitos livres A função seria algo como: TamMaximoNossoNumero:= 15; wTamNossoNumero:= length(NossoNumero); if ( (wTamNossoNumero >= 8 ) or (wTamNossoNumero <= 10)) or ( (wTamNossoNumero >= 14 ) or (wTamNossoNumero <= 15)) then TamMaximoNossoNumero = wTamNossoNumero; Acredito que desta forma manteríamos a compatibilidade para que o componente faça a formatação caso o usuário não tenha feito também atenderíamos corretamente o Nosso Número de 10 dígitos. Att
  20. Sem problemas, lembro sim mas estou pensando em fazer algo um pouco diferente, não sei se você viu como ficou a classe do Banco do Brasil a função CalcularTamMaximoNossoNumero, penso em fazer a mesma coisa para a caixa, apenas precisamos confirmar quais são os tamanhos válidos do nosso número livre(sem os prefixos), aparentemente seriam 8(sem os dois dígitos do prefixo) , 9(sem o digito do prefixo), 14(sem o digito do prefixo) e 10 e 15(ambos não utilizam nenhum prefixo). Att.
  21. Bom dia. Recentemente foram enviadas ao svn alterações para todas as classes para que seja feito um pad para formatar os campos corretamente. Att.
  22. Bom dia. Correção disponível no svn. Att.
  23. Bom dia Jeter. Quanto a alteração feita eu compreendi perfeitamente, minha pergunta é como você fez para testar o else da condição, ou seja (Length(ANossoNumero) > 11) ser falso, já que o setnossonumero sempre formata o nosso número com 15 posições. Att.
  24. Boa noite. Correção aplicada. Att.
  25. Boa noite Jeter. Fiz alguns testes com essa alteração, porém não consegui fazer com que caísse na situação dos 10 dígitos, como você fez este teste? Att.
×
×
  • 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.

The popup will be closed in 10 segundos...