Juliana Tamizou

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.

Anotações extraídas dos manuais fornecidos pelo banco Manual CNAB240 NOSSO NÚMERO IDENTIFICAÇÃO DO TÍTULO NO BANCO 041 048 9(08) DAC DÍGITO DE AUTO-CONFERÊNCIA NOSSO NÚMERO 049 049 9(01) Manual CNAB400 NOSSO NÚMERO IDENTIFICAÇÃO DO TÍTULO NO BANCO 063 070 9(08) NOTA 3 Orientações para o cálculo do DAC do Nosso Número que deixam claro que o 9º dígito é o DAC Para a grande maioria das carteiras, são considerados para a obtenção do DAC, os dados “AGÊNCIA / CONTA (sem DAC) / CARTEIRA / NOSSO NÚMERO”, calculado pelo critério do Módulo 10 (conforme Anexo 3). À exceção, estão as carteiras 126 - 131 - 146 - 150 e 168 cuja obtenção está baseada apenas nos dados “CARTEIRA/NOSSO NÚMERO” da operação. 1 – Exemplo: AG / CONTA = 0057 / 12345-7 CART / Nosso Número = 110 / 12345678-? Para baixar os manuais do banco utilizados no projeto acesse: https://acbr.svn.sourceforge.net/svnroot/acbr/tools/Bancos/Itau Att.

Boa tarde Marcelo. Você está usando a remessa padrão CNAB240 ou CNAB400 ? A melhor maneira de resolver será mostrando ao técnico as orientações pelo próprio manual fornecido pelo banco, após você informar qual padrão está usando posso te passar os trechos do manual que comprovam que o Nosso Número tem 8 dígitos. 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.

Bom dia. Veja oque diz o manual do banco: Agência Mantenedora da Conta Posição Inicial:53 Posição Final:57 Quantidade de Dígitos:5 Agência Mantenedora da Conta Código adotado pelo Banco responsável pela conta, para identificar a qual unidade está vinculada a conta corrente. Tamanho 5 posições. Preencher com zero a esquerda. Considerando essa orientação a rotina está correta, caso haja um novo manual por favor anexe aqui para ser analisado. Att.