Arquivo .txt

Volto a questionar,??? Não me agrada usar um forum para desenvolvimento compartilhado, e muito menos no forum onde o detentor eh o fornecedor da ferramenta.

Eu que eu quero dizer com ir para fora do SC é fazer “aplicações na mão”.

Quanto ao desenvolvimento compartilhado, sugiro algum SVN da vida. Nunca usei, mas ouço falar bem do Assembla.

Mas o ideal seria licenças de uso no mesmo servidor, com impedimento de ordem financeira talvez.

Eu concordo que deveria ser tudo dentro da ferramenta…

Mais eu vejo vários problemas… O primeiro é o editor da ferramenta, para fazer esse tipo de serviço é pra lá de ruim (Sem condições)… Segundo principalmente se for usar um SVN, seria melhor só atualizar as class externa… E dentro da ferramenta só faz as chamadas dos métodos passando parâmetros e tal…

Exatamente como funciona hoje o NFEPHP…

Pensa um usuário copiar todo código do nfephp para dentro do SC… No decorrer o pessoal corrige um bug e solta a atualização no SVN. Seria um transtorno principalmente se o desenvolvedor não acompanhasse todas as mudanças… Eu acho no futuro o usuário teria muitos problemas…

Principalmente os arquivos de remessa … que existes muitas e muitas particularidades… e muitos bancos também…

Tendo as class prontas, o usuário adapta no próprio sistema atual… Principalmente os sistemas que já gera boleto e não faz a transmissão do arquivo de remessa…

Bom essa é a minha opinião… Que não foge muito dos projetos que já vi por ai como acbr, nfephp e muitos outros…
Lembrando, estou falando de arquivo de remessa…

Eu fiz um pequeno exemplo, e se vcs acharem interessante eu posso continuar o da caixa econômica…

http://www.gestorcustom.com.br/bancos/remessa_retorno/remessa_caixa.rar

Concordo Régis.

Eu tinha me referido a fato da criação de boleto via formato livre, comentado pelo Haroldo.

Clayton e Haroldo, sobre desenvolver o boleto via formato livre, é uma coisa que é bom pensar bem!

A pergunta é!

1º) Por que desenvolver uma rotina que já existe e atende BEM?

2º) Não é mais fácil incorporar essa solução dentro da Ferramenta e aproveitar todo trabalho de VÁRIOS BANCOS já pronto e testado???

Contra:

1º) Provar que é possível desenvolver o boleto via SC!? A gente sabe e já foi provado que dá sim…

2º) Ou por que perder tempo para desenvolvimento VARIOS BANCOS e gastar mais fosfato, sendo que já existe essa solução e melhor em PHP ?

E outra, lembrando que de banco em banco existe suas particularidades…

O que vcs acham ?

Concordo,

Meus comentários se referem a usuários que precisam emitir boleto do banco do seu cliente. Ou seja, apenas boleto de um banco.

As macros do sc funcionam para a maioria dos bancos, estão prontas, o layout do boleto eh um so trocando apenas o logo do banco

Se não me engano phpboleto não exporta para pdf

Pesquisem codigo de barra no webhelp do sc.
No caso do PHP Boleto:

  • Primeiro o SC não tem repositório para classe, teríamos que mexer na coisa, ou ter scripts fora do sc e ao publicar se preocupar em fazer os uploads separadamente.
  • Segundo, o php boleto tem uma classe para cada banco, a programação, teria que ficar incluindo a classe conforme o banco desejado.

Template no SC:

  • O template é um só, não um para cada banco.
  • No site do Scriptcase em exemplos já tem um template pronto para uso
  • Os parâmetros de sacados e cedente são os mesmos, e as macros para impressão do código de barra e da linha digitável aceitam como parâmetro o código do banco.

Concluindo, mais padronização usando o SC e menos trabalho na programação.

*Retorno a participar aqui quando decidirem o ambiente que usaremos para compartilharmos efetivamente o desenvolvimento.

É muito difícil gerenciar o tempo entre ESTUDAR_APRENDER/PRODUZIR/CONTRIBUIR…

Mais vou fazendo conforme meu tempo aqui…


Fiz o ( Registro 0 ) e ( Registro 1 ) do manual.
CNAB 240 para o SINCO - Cobrança Bancária Caixa

Conforme vou evoluindo aqui, vou postando a class e um exemplo de uso.

http://www.gestorcustom.com.br/bancos/remessa_retorno/remessa_caixa.rar

Contribuindo um pouco com o topico pois sei que essa é a pedra no sapato de muita gente (como está sendo na minha)

Segue CNAB 400 versão 7.0 ITAU (em fase de testes) mais já tá com um bom caminho andado.

http://www.slords.com.br/cnab_itau/cnab_itau.rar

Estou “mexendo” e em outras funções e class do boleto (do itau) mais vendo o manual de cada banco, fica facil implementar com o banco que for necessario.

Novidades irei postando