Boleto Caixa SIGCB

[Rogerio]

Boa noite pessoal, estou precisando do boleto para a Caixa no layout
SIGCB e estou disposto a implementar ele, será necessário somente a
implementação do campo livre correto?

Se alguém estiver disposto a me ajudar ficarei grato, já aumentaria um
tipo de layout para o projeto também.


Att.

Rogério Kleinkauf

[Rômulo Augusto]

Boa noite Rogério!

Estamos aqui pra isso, pra ajudar!

Está correto, basta implementar o campo livre seguindo as orientações da documentação do layout. 

É muito bom saber que vc está disposto a contribuir com o projeto. Parabéns pela iniciativa!

Então é isso, se vc já tiver a documentação da CAIXA, manda pra a gente também blz?

Valeu

-------------------------------------------------------------------
Rômulo Augusto
JRimum Developer
www.jrimum.org

--
Você está recebendo esta mensagem porque se inscreveu no grupo "JRimum Community" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para jrimum-c...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para jrimum-communi...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/jrimum-community?hl=pt-BR.

[Rogerio]

Boa tarde Rômulo, bom fiz alguams implementações básicas, estou
trabalhando agora em cima da linha digitavel, acabei de subir para os
arquivos o src modificado assim como o maual da cef.

01 – 03 3 9 (3) Identificação do banco
04 – 04 1 9 Código da moeda (9 – real)
05 – 05 1 9 Dígito Verificador Geral do Código de Barras
06 – 09 4 9 Fator de Vencimento
10 – 19 10 9 (8) V99 Valor do Documento
20 – 44 25 9 (25) Campo Livre

Já é calculado esse Dígito Verificador Geral do Código de Barras? dei
uma olhadinha no projeto e não achei nada referente a isso, a maioria
é colocado manualmente certo?

Obrigado!

[Rômulo Augusto]

A biblioteca já calcula o que for necessário, inclusive o fator de vencimento a partir da data de vencimento.
O seu trabalho é apenas preencher o objeto título, criar um novo campo livre para o seu caso de acordo com a documentação da CEF e passar os dois para o objeto Boleto, o resto ele faz.

Quanto ao arquivo, não to conseguindo baixar, mas vou ver o que pode tá acontecendo...

Não sei se entendi direito, mas vc tá modificando a o fonte da lib eh isso? Se for, adianto logo pra vc que não precisa. O que muda de um banco/serviço pra outro é apenas o campo livre. O restante é padrão e é recuperado a partir do Titulo.


Depois posta os resultados aí!

Qualquer coisa, é só perguntar.

-------------------------------------------------------------------
Rômulo Augusto
JRimum Developer
www.jrimum.org

--

[Rogerio]

Boa noite, analizando melhor o código agora a tarde tens razão, nao
preciso calcular nada disso pois já calcula automáticamente

Já montei praticamente o campo livre, só está faltando o ultimo digito
no caso o Digito Verificador do campo livre

Simulei o digito 1 para o dv do campo livre e está dando um erro:

2010-07-25 22:56:26,020 ERROR main
utilix.AbstractLineOfFields.isConsistent (AbstractLineOfFields.java:
187)-
java.lang.IllegalStateException: O tamanho dos campos [ 7 ] é
incompatível com o especificado [4]!


esse seria o codigo para o campo livre:


ContaBancaria conta = titulo.getContaBancaria();

String nossoNumero = titulo.getNossoNumero();

this.add(new
Field<String>(conta.getNumeroDaConta().getCodigoDaConta()
+""+conta.getNumeroDaConta().getDigitoDaConta(), 7));

this.add(new Field<String>(nossoNumero.substring(0,3),
3));
this.add(new Field<Integer>(2, 1));

this.add(new Field<String>(nossoNumero.substring(3,6),
3));
this.add(new Field<String>("4", 1));

this.add(new Field<String>(nossoNumero.substring(6,15), 9));

this.add(new Field<Integer>(1, 1)); // Digito
verificador

no caso para o calculo dele seria:

Nota 1 - Os dígitos verificadores do Código do Cedente (posição “26”)
e do campo
livre do Código de Barras (posição "44"), são calculados da seguinte
forma:
• Módulo "11", com peso de 2 a 9, em que se o resultado da subtração
for maior
que 9, o DV será ‘0’, caso contrário o resultado será o próprio DV,
podendo ser
de 1 a 9;
• Para calcular o DV do código do cedente, considerar o conteúdo das
posições
20 a 25, sendo o sentido do cálculo da direita para a esquerda.
• Para calcular o DV do campo livre do Código de Barras, considerar o
conteúdo
das posições 20 a 43, sendo o sentido do cálculo da direita para a
esquerda.

tem algo pronto já em relação a isso?

Obrigado pela sua atenção Rômulo Augusto.

Logo finalizo e posto nos arquivos!

[Rogerio]

Já solucionado, falta somente o dv do campo livre.

[Rogerio]

Bom está quase finalizado, só estou com dificuldade para gerar o DV do
campo livre, Seria somente o calculo do modulo 11 correto? com peso de
2 a 9 e se o resultado for maior que 9 dv = 0,

Fiz mais ou menos isso

Modulo modulo11 = new Modulo(TipoDeModulo.MODULO11);
modulo11.setLimiteMinimo(2);
modulo11.setLimiteMaximo(9);

esse limite seria o peso?

StringBuilder numeroParaCalculo = new StringBuilder();

numeroParaCalculo.append(conta.getNumeroDaConta().getCodigoDaConta());

numeroParaCalculo.append(conta.getNumeroDaConta().getDigitoDaConta());
numeroParaCalculo.append(nossoNumero.substring(0,3));
numeroParaCalculo.append(2);
numeroParaCalculo.append(nossoNumero.substring(3,6));
numeroParaCalculo.append(4);
numeroParaCalculo.append(nossoNumero.substring(6,15));

System.out.println(numeroParaCalculo.toString());

System.out.println(modulo11.calcule(numeroParaCalculo.toString()));

está me retornando um valor que não está certo...

o que poderia ser?

[Gilmar P.S.L.]

Olá Rogério,

Pela documentação do campo livre que tenho aqui acho que deve ser assim:

        /*
         * 1º passo - Aplicar o módulo 11 aos dados do código de barras, o primeiro dígito da direita para a esquerda, será multiplicado por 2, o segundo, por 3 e assim sucessivamente até o 9;
         */
       
         int dvCampoLivre;
         
         StringBuilder numeroParaCalculo = new StringBuilder("123456..");//exemplo qualquer
         
         /*
          * 2º passo - Somar o resultado da multiplicação:
          */
         int soma = Modulo.calculeSomaSequencialMod11(numeroParaCalculo.toString(), 2, 9);
        
        /*
         * Obs.: Quando o resultado da soma for MENOR que o quociente (no caso 11),
         * ele deverá ser diminuído diretamente do quociente, obtendo-se o DV como resultado;
         */
        if (soma < 11) {
            dvCampoLivre = 11 - soma;
        } else {

            /*
             * 3º passo: dividir o resultado da multiplicação por 11
             */
           
            int restoDiv11 = soma % 11;
           
            /*
             * 4º passo - subtrair o resto da divisão de 11
             */
            int subResto = 11 - restoDiv11;
           
            if(subResto > 9){
               
                dvCampoLivre = 0;
               
            }else{
               
                dvCampoLivre = restoDiv11;
            }
        }

Confere com o que vc tem aí?

Olhei rápido, mas acho que isso.

--
Gilmar P.S.L.

[Rogerio]

Tentei usar o que o Gilmar fez, algumas vezes funcina, outras vezes me
retorna 10 como resultado

Módulo "11", com peso de 2 a 9, em que se o resultado da subtração for
maior
que 9, o DV será ‘0’, caso contrário o resultado será o próprio DV,
podendo ser
de 1 a 9;

Método:

private int calculeDigitoVerificadorDoCampoLivre(String
numeroParaCalculo){

int soma =
Modulo.calculeSomaSequencialMod11(numeroParaCalculo.toString(), 2, 9);

int dvCampoLivre;

if (soma < 11) {
dvCampoLivre = 11 - soma;

} else {

int restoDiv11 = soma % 11;

int subResto = 11 - restoDiv11;
if(subResto > 9){
dvCampoLivre = 0;
}else{
dvCampoLivre = restoDiv11;
}
}

return dvCampoLivre;
}


Alguma sugestão?

Obrigado

[Rogerio]

Numero gerado para o calculo

227102800020004017002536

com esse numero a function me retorna o valor 10, sendo que podia ser
somente de 1 a 9

[Rogerio]

Resolvido, vou pagar alguns amanha e se der tudo certo posto o src
completo

[Rômulo Augusto]

Valeu Rogério e desculpa pela demora.

Não sei como vc consertou aí, mas olhando para o preenchimento do "StringBuilder", talvez tenha faltando preencher alguns campos com valores a esquerda, zeros a esquerda por exemplo, pra completar os 24 dígitos.

No mais, estamos esperando sua validação aí com o banco.

-------------------------------------------------------------------
Rômulo Augusto
JRimum Developer
www.jrimum.org

[Rogerio]

Bom dia!

Tudo certinho com o Boleto Caixa SIGCB, a noite estarei postando o
src.


Obrigado pela ajuda de todos


Rogério Kleinkauf

[Rômulo Augusto]

Parabéns Rogério!!! Com certeza os seus créditos estará no Bopepo na próxima versão com o SIGCB.

-------------------------------------------------------------------
Rômulo Augusto
JRimum Developer
www.jrimum.org

--

[Misael Barreto de Queiroz]

Parabéns Rógerio, pela iniciativa e colaboração.

Um abraço.

Misael Barreto
JRimum Developer
www.jrimum.org

[Gilmar P.S.L.]

Olá Rogério, parabéns mesmo!

Se não for pedir muito :-), quando vc postar sua solução gostaríamos de ter também os boletos, ou se não for possível (devido a existência de dados reais), pelo menos os códigos de barras ou linha digitáveis usadas na homologação; é para nós colocarmos como caso de teste (nos testes unitários) do projeto.

Aproveitando a oportunidade, se vc ou pessoal da lista, tiverem casos homologados de outros bancos, podem postar na lista para a gente aumentar a testabilidade e conseqüentemente a qualidade do nosso projeto.

Mais uma vez para parabéns pela iniciativa Rogério.
--
Gilmar P.S.L.

[Rogerio]

Boa noite pessoal.

Como prometido vou postar o link das src das implementações aqui,
tentei subir pelos arquivos aqui do google, mas não está dando certo


http://visaosoft.com.br/rogerio/JrimumSIGCB.zip


Logo posto as linhas digitáveis!


Rogério Kleinkauf

[Rômulo Augusto]

Rogério, adicionei sua implementação ao projeto, vc pode acompanhar pelo timeline

Fiz apenas uma modificaçao na classe, colocando um "Filler.ZERO_LEFT" para o campo do código da conta. Assim garantimos que o campo sempre terá 6 dígitos (usei o exemplo da documentação pra validar).

Criei uma classe de teste, porém ficou pendente saber os valores das constantes. Na classe vc usou 2 e 4, na documentação eu vi 1 e 4 nos exemplos. De qualquer forma, a linha digitável que vc pagou vai tirar a dúvida.

No mais, parabéns mais uma vez pela implementação. Gostaria de destacar a atenção q vc teve aos detalhes, como por exemplos, usar os nomes dos métodos da mesma forma que estamos usando. O código está bem legível e o javadoc também está bom.

Só esqueceu uma coisa: colocar seu nome como autor da classe! hehehehe
Não se preocupe, já coloquei lá.

Valeu

-------------------------------------------------------------------
Rômulo Augusto
JRimum Developer
www.jrimum.org

[Karlos Thadeu]

Olá Rômulo,

No caso, se eu quiser baixar o novo projeto já com as novas atualizações eu baixo lá em "Browse source -> branches -> Bopepo-Maven"? É isso mesmo?

Pergunto isso porque ainda não foi criado a tag 0.2.2. =)

Atenciosamente,

2010/7/28 Rômulo Augusto <romul...@gmail.com>

[Rômulo Augusto]

Não cara. Como Gilmar disse, o "browse source" é uma forma de vc acompanhar o código, vc pode ver o código pelo browser. Ainda estamos vendo uma forma de tornar o SVN público. Essas novas alterações (SIGCB por exemplo), vão para o projeto quando a gente liberar a 0.2.3, no caso até o fim desse mês.

Valeu


-------------------------------------------------------------------
Rômulo Augusto
JRimum Developer
www.jrimum.org

[Karlos Thadeu]

Olá Rogério, acabei de testar as alterações que você fez para o banco CAIXA. 

A validação que estou fazendo para saber se está certo é verificando se a linha digitável dos boletos que eu gero com o programa da caixa (instalado na minha máquina por um técnico da CEF) estão condizendo com os gerados pelo framework. Resultado: Está tudo OK. =)

Porém, gostaria de ressaltar que os campos: "Nosso Numero" e "Ag/Cod. Cedente" não estão de acordo.

Busquei no site da CEF a documentação do SIGCB e a mesma diz o seguinte:

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

5.2 - Para impressão do bloqueto (quadro de impressão), no campo Nosso Número informar conforme orientações

abaixo:

O Nosso Número no SIGCB é composto de 17 posições, sendo as 02 posições iniciais para identificar a Carteira e as 15 posições restantes são para livre utilização pelo Cedente:  XYNNNNNNNNNNNNNNN-D, onde:

X -Modalidade Cobrança (1-Registrada/2-Sem Registro)

Y -Emissão do bloqueto (4-cedente)

NNNNNNNNNNNNNNN -Nosso Número (15 posições livres do Cedente)

D -Dígito verificador (pelo Módulo 11)

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Na versão atual do projeto as duas primeiras posições não estão sendo consideradas.

Já com relação a Ag/Cod. Cedente, o mesmo está exibindo a Agência com o seu DV. Ex.: 0758-1/215376-9, quando na verdade era para aparecer assim: 0758/215376-9

O restante está tudo OK

2010/7/28 Rogerio <rog...@visaosoft.com.br>

[Misael Barreto]

Olá Rogério, tudo bom?

Rogério, neste caso do SIGCB da CAIXA, não é que os campos "Nosso Numero" e "Ag/Cod. Cedente" estejam incorretos, pois esses campos são levados em conta na hora da geração de toda a informação do código de barras & linha digitável, inclusive do famoso campo livre. Como vocẽ mesmo pode avaliar, os dados estão corretos e estão batendo com os do software da CAIXA.

O que de fato acontece neste caso é que, NO MOMENTO DA EXIBIÇÃO, a regra deles exige que os campos "Nosso Numero" e "Ag/Cod. Cedente" sejam exibidos de maneira um pouco diferente, com informações a mais ou a menos, como você mesmo explicitou muito bem:


Nosso Numero
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

O Nosso Número no SIGCB é composto de 17 posições, sendo as 02 posições iniciais para identificar a Carteira e as 15 posições restantes são para livre utilização pelo Cedente:  XYNNNNNNNNNNNNNNN-D, onde:

X -Modalidade Cobrança (1-Registrada/2-Sem Registro)

Y -Emissão do bloqueto (4-cedente)

NNNNNNNNNNNNNNN -Nosso Número (15 posições livres do Cedente)

D -Dígito verificador (pelo Módulo 11)

Ag/Cod. Cedente
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Já com relação a Ag/Cod. Cedente, o mesmo está exibindo a Agência com o seu DV. Ex.: 0758-1/215376-9, quando na verdade era para aparecer assim: 0758/215376-9

Esse exibição um pouco diferente dos campos "Nosso Numero" e "Ag/Cod. Cedente" pode ser facilmente contornado redefinindo o conteúdo exibido por cada campo desses do template do boleto. Neste caso você nem precisa criar um template próprio do boleto, pode usar o template padrão, bastando apenas conhecer o nome dos campos e sobrescrever seus conteúdos, como se estivesse definido o conteúdo de novos campos de um template personalizado.

Faça o seguinte teste aí:

boleto.addTextosExtras("txtRsNossoNumero", "XX XXXXXXXX");
boleto.addTextosExtras("txtFcNossoNumero", "XX XXXXXXXX");
boleto.addTextosExtras("txtRsAgenciaCodigoCedente", "0758/215376-9");
boleto.addTextosExtras("txtFcAgenciaCodigoCedente", "0758/215376-9");

Você vai ver que apenas a exibição deste campos será afetada. A informação presente no código de barras & linha digitável permanecerá intacta, correta.

Espero ter ajudado,
Estamos à disposição.


Misael Barreto
JRimum Developer

[Misael Barreto]

Corrigindo o destinatário da mensagem...
É isso que dá responder as coisas sem tomar o café da manhã hehehheeh.
Abraço pra todos.

Olá Karlos Thadeu...

Karlos, neste caso do SIGCB da CAIXA, não é que os campos "Nosso Numero" e "Ag/Cod. Cedente" estejam incorretos, pois esses campos são levados em conta na hora da geração de toda a informação do código de barras & linha digitável, inclusive do famoso campo livre. Como vocẽ mesmo pode avaliar, os dados estão corretos e estão batendo com os do software da CAIXA.

[Gilmar P.S.L.]

É isso aí Karlos e demais..

Se vcs quiserem boletos 100% homologados, então provavelmente terão que mudar a formatação e alguns valores dos campos, e até mesmo mudar os labels desses campos no template do boleto. Por exemplo, tem banco que chama um campo de (Nosso Número / Código do Cedente) e outro chama de (NN/Número da conta).

Esses controles visuais serão implementados em versões posteriores. Mas se hoje quiserem boletos 100% homologados, então terão que fazer tais mudanças. Que se faz facilmente com o bopepo :-).

T+
--

Gilmar P.S.L.

JRimum Developer

.

[Ricardo JL Rufino]

No caso da personalização dos valores de exibição, o JBoleto possue na API alguns métodos que podem ser sobrecritos e personalizados pois cada banco tem uma regra(friscura) na exibição:
Ex: para o Santander eu precisei fazer.

/**
     * Recupera a a Agencia/CodCedente no padrao especificado pelo banco
     * @author Welson Santos
     */
    @Override
    public String getAgenciaCodCedenteFormatted() {
        Integer f1 = Integer.parseInt(boleto.getAgencia().substring(0, 3));
        Integer f3 = Integer.parseInt(boleto.getContaCorrente());
        Integer f4 = Integer.parseInt(boleto.getDvContaCorrente());

        return String.format("%04d / %01d - %01d", f1, f3, f4);
    }

Espero ter ajudado.

[Gilmar P.S.L.]

Valeu pela dica Ricardo,

Mas como o Misael falou, no bopepo é muito mais fácil :-) basta fazer o seguinte:

boleto.addTextosExtras("txtRsNossoNumero", "XX XXXXXXXX");
boleto.addTextosExtras("txtFcNossoNumero", "XX XXXXXXXX");
boleto.addTextosExtras("txtRsAgenciaCodigoCedente", "0758/215376-9");
boleto.addTextosExtras("txtFcAgenciaCodigoCedente", "0758/215376-9");

Não precisa herdar nem re-implementar nada isso é sobrescrita de campos (Convention over Configuration). E como alguns bancos tem até a disposição dos campos diferentes... (aí vc vai ter que mexer no template, e no bopeo é super fácil :-)

[Karlos Thadeu]

Blz ficou claro agora. Vou fazer o teste ainda hoje, porém gostaria de tirar mais uma dúvida:

Para eu calcular o DV do nosso número e setar corretamente no objeto titulo eu devo chamar o método "Modulo.calculeMod11(titulo.getNossoNumero(), 2, 9)";

É isso ?

Atenciosamente,

2010/8/4 Gilmar P.S.L. <gilm...@gmail.com>

[Gilmar P.S.L.]

Fala Karlos,

Na verdade não, no código atual:

http://www.jrimum.org/bopepo/browser/branches/0.2-Helio/src/main/java/org/jrimum/bopepo/campolivre/CLCaixaEconomicaFederalSIGCB.java

A linha 146 calcula o DV utilizando o método calculeDigitoVerificador na  linha 208.

É uma dúvida que estamos em relação a Conversão desses dígitos, acho que dígitos de contas e de nosso número, agência, etc..
Serão fornecidos no título por quem está gerando o boleto.

Mas na verão atual não precisaria.

Já dando uma prévia do que vem por aí,...

Para facilitar essa conversão, esses números serão tipados em objetos separados, como planejado por nós e proposto aqui pelo colaborador Hermes Hostin.

[Karlos Thadeu]

Então recaptulando,

Na versão que eu estou hoje, que método eu chamo para calcular o meu DV do nosso número ?

titulo.setDigitoDoNossoNumero(???);

pergunto isso pq o método "calculeDigitoVerificador" é privado

Atenciosamente,

2010/8/4 Gilmar P.S.L. <gilm...@gmail.com>

Fala Karlos,

[Rômulo Augusto]

Cara, o cálculo do Nosso Número é vc quem deveria fazer. É isso que Gilmar falou. Ele já deveria ir calculado quando vc passa o título pra o objeto Boleto.

O que você pode fazer é aproveitar o código que tá feito no campo livre. Não tem como usar o método do objeto campo livre em si, até porque a classe é protegida de pacote e o método privado.

-------------------------------------------------------------------
Rômulo Augusto
JRimum Developer
www.jrimum.org

[Karlos Thadeu]

Blz então. Agora ficou claro.

Muito obrigado pela ajuda de todos

2010/8/4 Rômulo Augusto <romul...@gmail.com>

[Gilmar P.S.L.]

Blz Karlos,

Coloquei muita informação aí mistura tudo..., mas vamo lá...
Para o snapshot que vc tem..., vc não percisa calcular, por que como eu disse:

http://www.jrimum.org/bopepo/browser/branches/0.2-Helio/src/main/java/org/jrimum/bopepo/campolivre/CLCaixaEconomicaFederalSIGCB.java

A linha 146 calcula o DV utilizando o método calculeDigitoVerificador na  linha 208.

Então vc não precisa passar. O método é privado mas o cálculo é feito dentro do campo livre. Basta então vc apenas fornecer o número da conta sem ou com dígito. O calculo será feito dentro do campo livre. A diferença será na visualização. Com o dígito aparece, sem o dígito não aparece. Mas de qualquer jeito ele é calculado no campo livre.

Isso que to falando é do dVCodigoDoCedente. O campo livre não calcula o dígito do nosso número não. Desculpe.
--
Gilmar P.S.L.

[Karlos Thadeu]

Pronto pessoal. Tudo Ok. Breve enviarei para a Caixa homologar apenas para desencargo de consciência.

Em anexo segue o boleto estilo carnê.

Com esse novo modelo de boleto surge a seguinte dúvida: Tem como colocar vários boletos na mesma página ? Pois nesse estilo carnê tem como colocar 3 por páginas.

Atenciosamente,

2010/8/4 Gilmar P.S.L. <gilm...@gmail.com>

Blz Karlos,

[Gilmar P.S.L.]

Fala Karlos,

Cara, estamos bastante contentes com o desenrolar desse desenvolvimento. Ficou muito legal o template..
Mas to meio receoso se a caixa vai aprovar esse estilo carnê. O problema que vejo é o layout. A documentação diz que o boleto deveria seguir aquele modelo descrito lá. Mas isso aí é com eles.

Quanto a possibilidade de se colocar 3 boletos na mesma página...?
Sim, dá pra fazer, agora teríamos que criar um método para isso e os 3 boletos no template teriam que ter nomes de campos diferentes.
Tipo:

• txtFcLinhaDigitavel1
• txtFcLinhaDigitavel2
• txtFcLinhaDigitavel3

Agora a minha dúvida é se os 3 boletos são de títulos diferente ou do mesmo título. Só pra saber. E se vc realmente quiser fazer nesse estilo 3 em 1, é só avisar. Valeu.
--
Gilmar P.S.L.

[Karlos Thadeu]

Quando você diz: "Mas to meio receoso se a caixa vai aprovar esse estilo carnê."

Eu tenho certeza que sim, pois o próprio programa disponível por eles para gerar boletos existe essa opção. Esse template que eu fiz é uma cópia fiel a deles (exceto pela adição do campo "Parcela" do recibo do sacado). Mas de qualquer forma em breve irei homologar e digo a vocês.

Com relação a vários boletos em uma folha eu me refiro por exemplo a um carnê com 6 parcelas, que serão impressos 6 boletos em apenas duas folhas. Onde cada boleto vai ter o seu campo parcela (motivo pelo qual eu criei o campo "parcela" no recibo do sacado) e sua data de vencimento. =)

Atenciosamente,

2010/8/4 Gilmar P.S.L. <gilm...@gmail.com>

Fala Karlos,

--
Gilmar P.S.L.

--

[Luiz Carlos Santos]

Já desenvolvi um projeto em python para cliente e os boletos eram da Caixa eram tipo carnê 3 por página
Tenho certeza que homologa
Bom trabalho pessoal !!! Parabéns pela iniciativa

Luiz Carlos

[Gilmar P.S.L.]

Olá Karlos,

Minha opinião é com base no layout da caixa, lá tem um padrão de impressão diferente. Agora, como vc disse que no programa tem esse exemplo e o colega Luiz Carlos Santos também falou que já fez assim, então blz, é isso aí. Resta só a parte prática do preenchimento dos dados.

Quanto a isso, eu entendi o esquema das parcelas. Então, quer dizer que...:

1. Cada parcela tem um nosso número diferente
2. Cada parcela tem um vencimento diferente

Então, cada parcela é um título diferente, com um código de barras diferente. Portanto, teremos que criar um novo mecanismo (método) para fazer esse preenchimento de dados na mesma folha, confere Karlos?

T+
--
Gilmar P.S.L.

[Karlos Thadeu]

Confere. É isso mesmo. =)

2010/8/5 Gilmar P.S.L. <gilm...@gmail.com>

--

[Gilmar P.S.L.]

Ok, blz, então prepara o template com os 3 boletos aí pra gente fazer a implementação.

T+
--
Gilmar P.S.L.

[Karlos Thadeu]

Olá Gilmar, Mas essa seria realmente a melhor solução  (template com 3 boletos ) ?

Porque tipo, quando for imprimir um carnê com 4 parcelas como iria sair ?

2010/8/5 Gilmar P.S.L. <gilm...@gmail.com>

T+
--
Gilmar P.S.L.

--

[Gilmar P.S.L.]

Karlos, quando eu vi o pessoal querendo mais de um boleto na mesma página, ...
Era pessoal de gráfica, onde o principal requisito era economizar papel. nesse caso eles cortavam e faziam o "talão".

Agora para clareza, tem gente que prefere um por folha. Mas isso aí é vc ou o pessoal do seu negócio que irá decidir. Agora notei que no seu template não tinha texto. Dependendo do caso, vc poderia colocar informativos (imagens e textos). Mas, é como eu disse, depende do teu negócio (domínio) aí.

T+
--
Gilmar P.S.L.