Arquivo .txt

Programação Sistemas
#7

me candidato a gerenciar, uma vez que, além de necessitar disso também esta talvez seja minha maior forma de auxiliar, já que sou inexperiente em php, porém, habil em outras facetas necessarias.

Estou me aconselhando com os administradores a respeito de um thread especial para isso com a liberação de anexos ali.

MAS SALIENTO que, o forum tem sofrido ataques excessivos de bots com material improprio e fui um dos que pedi a remoção dos anexos nos posts.

Vou me aconselhar e retorno com a posição dos administradores.

Todavia fica a critério de voces quem será o centralizador disso.

abraços

#8

AVISO:

A netmake nos brinda com uma nova seção para colocarmos projetos de colaboração opensource. O link está abaixo.

O primeiro projeto será o tão solicitado “Cobrança Bancária”. Todos os que se candidatam para esse empreendimento, por favor, notifiquem (acessem, deixem recado, disponibilizem material, etc) nesse local.

abraços e parabéns à iniciativa dos usuários que deram a idéia e se colocaram à disposição.

http://www.netmake.com.br/forum/index.php?topic=3940.0

#9

Comecei esse trabalho mas não terminei, tenho a modelagem e a analise de todas as apps, se tiverem interessados posso disponibilizar.

#10

Com certeza Haroldo, acredito que seja muito interessante ter seu material!

#11

isso é maravilhoso haroldo. Acredito que, juntando os pedaços de cada um, logo teremos uma estrutura boa de trabalhar.
Também tenho uma peça do quebra-cabeças que vou colocar.

#12

Não sei como o vcs pensam, mais a principio eu acho interessante criar class que atente e fácil implementação no erp de cada um… partindo que a logica de cada um é diferente…

Então a parte de geração de arquivo de remessa teria que ser uma class onde seria passado os valores para ela… a partir dos valores passado, a class geraria o arquivo de remessa seguindo o layout… assim cada usuário que queria usufruir e implementar no seu sistema o arquivo de remessa… já ficaria meio caminho andado… assim como o próprio boletophp funciona hoje…

a parte de impressão, como cada banco tem seu particular… eu estou utilizando o www.boletophp.com.br que é fácil e rápido para implementar…

O que vcs acham?

#13

Pensava em um módulo financeiro com Contas a Receber, Históricos, etc, com a implementação do boleto bancário.

Porque assim? Me imagino na situação (real) de saber pouco da ferramenta e de php. Além do que, a remessa é apenas um dos pontos necessários para cobrança; tem também o retorno, seleção do que emitir/imprimir, a impressão, reimpressão, cálculo de juros para reemissão, gráficos, etc.

Lendo os posts antigos do regis, fui até o boletophp e baixei o dito. (é muito bom mesmo).
Mas como tenho certa preferência em concentrar tudo em um único lugar, fiz também o que o arquimedes fez, em estilo livre. Assim, fico com tudo na ferramenta principal de desenvolvimento.

Minha idéia é que, depois de pronto, todos possam importar em suas aplicações os módulos desejados e usá-los diretamente E/OU consultar as aplicações disponibilizadas para consulta pessoal e adaptar segundo seus preceitos.

Como é mais fácil analisar algo que se pode ver, posso disponibilizar um modulo financeiro (não está pronto ainda) para que sirva de “pontapé inicial”.

à disposição

abraços

#14

o módulo se chama TED (Transferência Eletrônica de Dados).

Consiste no cadastro e importação dos layouts bancários.
Envio do CNAB de remessa baseado num borderô de cobrança
Instruções Bancárias
Importação do arquivo de Retorno
Geração do Boleto Bancário com envio por email

Pode parecer pouca coisa, mas é um sistema grande.

Não envolve financeiro, e não acho que deva envolver.

#15

Também acho que não teve envolver financeiro…

Cada desenvolvedor tem seu particular conforme o cliente e tal…

De repente podemos iniciar com class reutilizável no decorrer vamos amadurecendo…

assim podendo se adaptar em qualquer sistema financeiro… principalmente os que já emitem boletos…

#16

A princípio concordo com o Haroldo e com Régis.

Também tem a questão da necessidade de um usuário que já tem sua estrutura do sistema pronta com um cliente antigo e pinte a necessidade de criar um arquivo de remessa ou gerar boletos.(Já conversei sobre isso com Régis)
Este usuário tem que conseguir usar a classe criada sem necessitar alterar a estrutura de seu sistema.

Não acham?

#17

muitas cabeças… muitas ideias… …todos certos.

concordo com a criação da classe em separado. Minha ideia inicial é uma tolice analisada do ponto de vista já comentado.

alguem tem uma estrutura basica para dar inicio?

ou alguem desenha esta estrutura para ir amadurencendo a ideia ?

ela conterá remessa, retorno e impressão?

se alguem que tem experiencia com classes em php fizesse um pseudo-codigo apenas da classe e alguns metodos, daria uma visão melhor do que estamos plantando, e enxertaríamos demais métodos.

regis e haroldo, experts, você (regis) usou a classe do boletophp e imagino que esteja familiarizado com ela. Conseguem fazer um pseudo-codigo simples para nós?

#18

Vou fazer aqui… BLZ…

#19

Porque nao usar um template livre do sc para fazer os boletos?se formos ficar incorporando classes externas o objetivo do projeto perde o foco, que desenvolver em sc. Eu posso modelar o sistema.

#20

Concordo Haroldo!!!

Particularmente, só vou para fora do SC quando o SC me obriga.

#21

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.

#22

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.

#23

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

#24

Concordo Régis.

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

#25

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 ?

#26

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.