Ir para conteúdo
  • Cadastre-se

Juliana Tamizou

Administradores
  • Total de ítens

    14.816
  • Registro em

  • Última visita

  • Days Won

    188

Tudo que Juliana Tamizou postou

  1. Bom dia. Estão disponiveis no svn tanto a Cobrança SICOB como a SIGCB para a Caixa, basta escolher o tipo enumerado correspondente nas propriedades do componente. Att.
  2. Boa tarde. Vc pode comentar o uses deste componente, um outro usuario comentou que o o componente do Código de Barras do QuickReport não estava funcionando bem, por isso usou este outro componente. Att.
  3. Bom dia. Neste tópico foi mencionado como resolver o problema: viewtopic.php?f=11&t=2342&hilit=nelson A solução aplicada pelo Nelson está disponível no svn desde o dia 07/07/2011. Att.
  4. Eu entendi oque vc disse Elton, eu quis dizer que caso alguém tenha esse documento com explicações gerais sobre a geração de boletos ou se proponha a fazer, pode postar. Apesar de nos manuais do Bradesco e de alguns outros bancos, este processo estar bem detalhado. Att.
  5. Bom dia. Não tem nenhum documento explicativo mesmo, apenas o demo, quem tiver algo escrito e quiser postar aqui, pode ficar a vontade. Att.
  6. Bom dia. Vc pode anexar aqui o manual do banco, que fala sobre o dígito verificador? Att.
  7. Bom dia. 1)É possível sim, cancelar um boleto remetido, basta usar o Tipo de Ocorrência correto. 2)Para o seu tipo de convênio(com 4 digitos) ainda não testei o retorno, porem se forem necessários ajustes, acredito que serão poucos. Att.
  8. Boa tarde. Vc instalou esse componente tb? Caso vc mantenha comentado essa linha comentada, vc nao consegue imprimir os boletos mesmo assim? Att
  9. Bom dia. Eu recompilei o package do ACBrBoleto e também o demo, ambos estão compilando normalmente. Tente remover e instalar novamente o componente.
  10. Boa tarde. Vc está com seus fontes atualizados? Hoje foram enviadas diversas alterações para o svn. Att.
  11. Boa tarde Douglas. Sua alteração já está no svn. Att.
  12. Bom dia Jeter. Sua correção já está no svn. Att.
  13. Bom dia. Foi necessário modificar a forma de setar qual classe de banco será utilizada. Necessidade surgiu pois, a Caixa Econômica Federal, possui dois manuais de geração de arquivos e também de impressão de boletos, um para o convênio SICOB e outro para o SIGCB, totalmente distintos. Conforme o Jeter Rabelo levantou diretamente com o suporte da Caixa, não é possivel definir qual layout deve ser usado com base no número do convênio e nem em qualquer outra informação, por isso, foi necessário a utilização de duas classes para a Caixa, uma para cada convênio. Como o número do banco permanece o mesmo, não é mais possivel selecionar a classe a ser instanciada atraves desta propriedade, então foram feitas as seguintes alterações: 1-) Criado o Tipo Enumerado TACBrTipoCobranca, para todos os bancos, nesta lista temos o tipo cobCaixaEcomica e cobCaixaSICOB. 2-) Criado a propriedade TipoCobranca para a classe banco, com esta propriedade será definida qual classe deverá ser instanciada. 3-) Com as mudanças acima, foi alterada a propriedade número para ser Ready Only. Já efetuei testes em nosso programa e desta nova maneira, o componente está funcionando perfeitamente. Att.
  14. Bom dia. Conforme o manual do Bradesco : 109 a 110 - Identificação de Ocorrência. Você deve informar o tipo de ocorrência correto, para a remessa de inclusão de titulos você deve utilizar o tipo "toRemessaRegistrar". Att.
  15. Bom dia. Quais são as informações do seu boleto (Nosso Número, valor, vencimento, carteira, codigo do cedente, conta,agencia,etc...) Att.
  16. Boa tarde Giuliano. Ainda não recebi nenhuma contribuição referente a estas alteração do Outros Acrescimos e Outras Deduções... se quiser pode postar aqui. Att.
  17. Acho que assim fica melhor mesmo. Att.
  18. Bom dia Jeter. Estive pensando em criar uma propriedade TIPOCONVENIO, como tipo enumerado, então poderiam existir inicialmente 3 tipos oCobGeral(para não atrapalhar os demais bancos que não necessitam dela), oCobSICOBCaixa e o oCobSIGCBCaixa. Acho que isso já resolveria nosso problema. Att.
  19. Bom dia. Eu acho que o toRemessaOutrasAlterações deve servir, mas achoe melhor você confirmar isso no banco. Att.
  20. Boa tarde. Então o tamanho do código do cedente também não pode ser usado para definir o tipo de cobrança, já que você disse que é sequencial. Se não houvesse nenhum cliente com as excessões que você mencionou, poderiamos utilizar os 3 primeiros digitos como padrão. Outro detalhe que percebi é que mesmo para impressão e geração da remessa, o tamanho do código do cedente não é algo que possa ser utilizado para definir como essas operações devem ser feitas. Estou começando a pensar que nossa unica opção passa a ser, criar uma propriedade para o tipo do convenio a ser seguido. Att.
  21. Boa tarde. Suas correções para o QuickReport já estão disponiveis no svn. Att.
  22. Boa tarde. As correções para o Sicred já estão disponiveis no svn. Att.
  23. Boa tarde Tiago. Se quiser fazer o layout da fatura fique a vontade, até o momento não recebi nenhuma contribuição relacionada a isso. Eu acho que no boleto fatura, deve ser parecido com as faturas de cartão de crédito, onde existe um demonstrativo com as "contas" que estão sendo cobradas... O log do cliente seria interessante também. Quanto a sua dúvida referente a Remessa, você pode usar o tipo "toRemessaAlterarVencimento", para alterar o vencimento. Att.
  24. Boa tarde. Verificado que o problema ocorreu porque recebemos uma contribuição para imprimir também o logo da loja, porém faltou o dfm. Corrigido problema e postado no svn. Att.
  25. Boa tarde Tiago. Você pode por favor anexar aqui também os arquivo .dfm da classe do Fortes? 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.