Juliana Tamizou

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.

Boa tarde. Vc instalou esse componente tb? Caso vc mantenha comentado essa linha comentada, vc nao consegue imprimir os boletos mesmo assim? Att

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.

Boa tarde. Vc está com seus fontes atualizados? Hoje foram enviadas diversas alterações para o svn. Att.

Boa tarde Douglas. Sua alteração já está no svn. Att.

Bom dia Jeter. Sua correção já está no svn. Att.

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.

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.

Bom dia. Quais são as informações do seu boleto (Nosso Número, valor, vencimento, carteira, codigo do cedente, conta,agencia,etc...) Att.

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.

Acho que assim fica melhor mesmo. Att.

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.

Bom dia. Eu acho que o toRemessaOutrasAlterações deve servir, mas achoe melhor você confirmar isso no banco. Att.

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.

Boa tarde. Suas correções para o QuickReport já estão disponiveis no svn. Att.

Boa tarde. As correções para o Sicred já estão disponiveis no svn. Att.

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.

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.

Boa tarde Tiago. Você pode por favor anexar aqui também os arquivo .dfm da classe do Fortes? Att.

Bom dia. Ainda sobre o tamanho do Código do Cedente, vc sabe me dizer se existe a possibilidade de comecar com 0?...pq senão podemos entender que os 0(zeros) a esquerda que retornarem no arquivo podem ser ignorados, dessa forma saberíamos o tamanho do Código do Cedente, mesmo no arquivo retorno. Acho que se não for possivel dessa maneira, só resta criar a propriedade mesmo. Att.

Bom dia. Vc tem alguma mensagem de erro ao listar o carnê? Qual o gerador que você está utilizando? Att.

Bom dia Jeter. Pelo tamanho do número do cedente não era possivel definir qual layout está sendo utilizado? Att.

Bom dia. O componente, faz a montagem dos arquivos remessa, gera o boleto impresso, e para vários bancos implementados também faz a leitura do arquivo retorno, isso seguindo as regras de montagem do arquivo, calculo do nosso número, montagem da linha digitável e etc... Para tanto é necessário apenas passar ao componente as informações referentes aos boletos que se deseja imprimir. O demo é simplesmente um exemplo de como alimentar o componente. Att.

Bom dia. Qual versão do Fortes vc instalou? Att.

Bom dia. Você pode aumentar o componente usado para o Local de Pagamento, acho que se ele ficar mais alto já resolve, ai é só mudar a propriedade wordwrap para false, se não me engano. Att.