Juliana Tamizou

Boa tarde Douglas. Correção disponível no svn. Att

Boa tarde. Pela quantidade de caracteres que foi informado que o ACBr leu, a clase utilizada deve ter sido a CaixaSicob, pois a a unit do SIGCB(CaixaEconomica) lê apenas 11 dígitos. Para facilitar a análise anexe aqui seu arquivo retorno e também as informações da conta. Att.

Boa tarde Antonio. Realmente estes arquivos estão sendo gerados sem as informações que você citou, se desejar implementar e quiser compartilhar com todos, poste aqui. Att.

Boa tarde. Apenas a agência e conta são impressos no campo Código do Cedente. Qual a necessidade desta outra informação? Att.

Boa tarde. Qual informação exatamente você precisa? Existe alguma tabela de valores ou algo assim? Att.

Boa tarde Sergio. As regras para calculo do digito verificador variam por banco, por isso você deverá observar a função CalcularDigitoVerificador implementada para cada banco. Att.

Boa tarde. Com um pouco de atraso, mas as alterações estão no svn. Att.

Boa tarde. Observe o seguinte post viewtopic.php?f=11&t=8050. Att.

Boa tarde. O problema ainda persiste? Se sim, seu Fortes está atualizado? Fiz um teste com 95 boletos e não tive nenhum problema. Att.

Bom dia. Qual erro você está tendo? Att.

Bom dia. Qual é exatamente o problema que você está tendo? Att.

Boa tarde. Quanto a Data de Baixa e Data de Crédito, acredito que seja devido ao prazo para o valor ser creditado na conta da empresa após o pagamento do boleto, por isso acredito que o correto seja usar a Data de Baixa. Quanto a ocorrência 17, acredito que seria interessante confirmar esta informação junto ao banco. Att.

Boa tarde. Ao gerar o SPED Fiscal reparei que os espaços no final dos campos como Endereço, Numero, Bairro, etc... não estão sendo removidos, fazendo com que o arquivo não seja validado. Reparei o problema no registro 0150, mas acredito que qualquer registro com campos String terá o mesmo problema.

Boa tarde Junior. O Banco Nordeste foi adicionado sim ao svn, assim que concluirmos a análise desta nova versão adicionaremos ao svn. Att

Bom dia. O problema só ocorre com a Caixa ou em qualquer banco? Att.

Bom dia. Com essa lista fica mais fácil ler, porém no change log também é possível acompanhar os bancos que já foram implementados Att.

Bom dia. Aparentemente existe um erro no manual do banco, pois ele diz: "Se o módulo da divisão anterior for igual a ‘0’ (Zero) ou ‘1’ (um) o dígito verificador será ‘0’ (zero), para qualquer outro valor Subtrair o módulo do número 11 para obter o dígito verificador " 0*8=0 2*7=14 1*6=6 9*5=45 9*4=36 2*3=6 1*2=2 Soma = 109 Mod 11 = 10 DV= 1 Por favor solicite junto ao banco um novo manual para verificarmos se houve alguma alteração nas regras de calculo do DV do Nosso Número.

Bom dia. Existe um manual específico para este tipo de remessa e retorno? Att.

Bom dia. Você pode utilizar a função MontarCampoNossoNumero() Att.

Bom dia. Por favor anexe o manual utilizado aqui, para que possamos disponibilizar para todos os usuários do componente. Att.

Bom dia. Apenas gostaria de confirmar a razão da troca do "041" por "40" no final da atribuição, pq não ficou apenas "41" ? CampoLivre:= Modalidade +'1'+ padR(copy(ACBrBoleto.Cedente.Agencia,1,4), 4, '0')+{ Código agência (cooperativa) } padR(ACBrBoleto.Cedente.Conta, 7, '0')+{ Código cedente = Número da conta } padR(NossoNumero, 8, '0')+{ Nosso número } '40'; Att.

Bom dia. Esses bancos são confusos msm...correção já está disponível no svn. Att.

Sem problemas, você chegou a efetuar a correção e enviar novamente o arquivo ao banco? Se possível tentar homologar com os "9" e caso der certo postar aqui. Att.

Bom dia. Existem pessoas utilizando este banco sim, inclusive recentemente foram enviadas algumas correções para esta classe. Como você está preenchendo o componente e qual a diferença encontrada? Att.

Bom dia. Veja oque diz o manual do Banco " 340-353 CIC/CGC do sacador avalista 99999999999999" Acredito que seria melhor verificar com o banco a forma correta de informar este campo, já que os "9"s indicam que é um campo numérico e por consequência o correto não seria preencher com espaços. Att