Juliana Tamizou

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.

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.

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.

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.

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.

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.

Bom dia Maicon. Qual padrão você está utilizando, SICOB ou SIGCB? Att.

Bom dia. Foi postada esta semana uma correção para o Banrisul, efetue os testes novamente após baixar o svn. Att.

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

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.

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.

Bom dia. Correção disponível no svn. Att.

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.

Boa noite. Correção aplicada. Att.

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.

Boa noite. Para facilitar os testes informe os valores passados ao componente, exemplo Convênio = 1234567, etc... Att.

Boa noite Nazareno. Alteração disponível no svn. Att.

Boa noite Bruno. Você falou com suporte do banco sobre este problema? Att.

Boa tarde. As alterações que fiz foram na unit CaixaEconomica, apesar de estarem corretas não é oque você deve usar. Está disponível no svn a correção para a unit CaixaEconomicaSicob, onlynumber não remove os "0", oque estava causando o problema era o fato de não estar definido para esta classe o tamanho correto dos campos Agência e Conta.. Att.

Bom dia Fábio. Para acompanhar as atualizações do componente faça a atualização via svn utilizando o seguinte endereço: https://acbr.svn.sou...root/acbr/trunk. nele você encontrá um demo de como utilizar o componente. Att.

Bom dia. Informe o código do cedente conforme passado pelo banco exceto o digito verificador, ou seja, 166087000000032. Att.

Bom dia. Como está configurado seu componente e quais as informações passadas para os titulos(carteira e nosso número) ? Att.

Bom dia Fábio. O número do convênio é informado diretamente no componente. Se for necessário o componente irá calcular o DV. Para baixar os fontes e demos dos componentes ACBr acesse: https://acbr.svn.sourceforge.net/svnroot/acbr/trunk Att.

Bom dia. Na verdade baseado nos testes que fiz com seu arquivo o único problema estava relacionado a conta, pois esta unit não utiliza esta propriedade apenas o CodigoCedente. Estão disponíveis no svn os fontes com um ajustes para que seja feita a validação de forma correta destas informações, após efetuar a atualização do componente o arquivo será processado. Att.

Bom dia Lemarq. Já está disponível no svn a correção para seu problema, o mesmo ocorria devido ao Banco do Brasil possuir 2 opções de uso para as carteiras 16 e 18 com convênio de 6 posições, sendo a primeira a forma como estava sendo impresso seu Nosso Número (com 17 posições apenas para o valor do Nosso Número) e a outra a forma que você precisava (6 posições para o convênio e 4 para o Nosso Número). Para que ambos os casos funcionem corretamente é necessário se atentar para os seguintes pontos, além é claro de informar corretamente a carteira e o convênio: Para utilizar o Nosso Número de 17 posições informe um Nosso Número com pelo menos 11 dígitos(preencha com zeros a esquerda se desejar). Para utilizar o Nosso Número de 11 posições (6 Convênio + 5 Nosso Número) informe o nosso número com até 5 posições. Att.