Projeto PAI de aplicações diversas
29/09/2004
0
Caros colegas,
lendo alguns artigos aqui do site, não precisa ser um gênio para a conclusão a seguir:
- num dos artigos alguém relata o fato que muitas empresas e profissionais tem seu custo aumentado em função de ter diversos clientes em áreas diferentes como comércios de autopeças, farmácias, loja de roupas, serviços mecânicos, TV a cabo, escritórios de direito, etc etc etc.
O tempo perdido para se adaptar o básico, como contas a pagar e a receber, cadastros de clientes, fornecedores e produto, escrituração fiscal, folha de pagamento, entre muitas outras coisas em comum, acabam elevanmdo não só o custo de produção, mas de manutenção dos softwares. Se perde em lucro e o cliente perde em qualidade e custo benefício.
Então vem a idéia: vamos começar a desenvolver um sistema básico e comum a todos, reunindo tanto o know how prático de cada área comum(cadastros, financeiro, fiscal, contábiç, etc) como técnico (programação, documentação, otimização de sistemas, criação de omponentes, APIs, etc) de forma o código fonte estar disponível, bem como a documentação, de uso livre como o Linux ?
Aguardo sua resposta, um abraço.
lendo alguns artigos aqui do site, não precisa ser um gênio para a conclusão a seguir:
- num dos artigos alguém relata o fato que muitas empresas e profissionais tem seu custo aumentado em função de ter diversos clientes em áreas diferentes como comércios de autopeças, farmácias, loja de roupas, serviços mecânicos, TV a cabo, escritórios de direito, etc etc etc.
O tempo perdido para se adaptar o básico, como contas a pagar e a receber, cadastros de clientes, fornecedores e produto, escrituração fiscal, folha de pagamento, entre muitas outras coisas em comum, acabam elevanmdo não só o custo de produção, mas de manutenção dos softwares. Se perde em lucro e o cliente perde em qualidade e custo benefício.
Então vem a idéia: vamos começar a desenvolver um sistema básico e comum a todos, reunindo tanto o know how prático de cada área comum(cadastros, financeiro, fiscal, contábiç, etc) como técnico (programação, documentação, otimização de sistemas, criação de omponentes, APIs, etc) de forma o código fonte estar disponível, bem como a documentação, de uso livre como o Linux ?
Aguardo sua resposta, um abraço.
Amjorge
Curtir tópico
+ 0
Responder
Posts
29/09/2004
Aroldo Zanela
Colega,
Você conhece?
Projeto Automação Comercial Brasil
http://acbr.sourceforge.net
Você conhece?
Projeto Automação Comercial Brasil
http://acbr.sourceforge.net
Responder
29/09/2004
Amjorge
Já havia visto, mas bem por cima. O objetivo deles é parecido, porém com ênfase na automação comercial, mais especifricamente no hardware de automação comercial.
O que proponho é uma coisa bastante simples que seria o que chamamos de módulos básicos ou comuns a praticamente todo sistema de cunho comercial, que seria o cadastro e a parte fiananceira contábil. Além de ser bem mais abrangente.
O custo desse nosso desenvolvimento seria dividido entre os coloboradores e pago com horas de trabalho. A idéia é parecida, mas o escopo diferente.
Um abraço.
O que proponho é uma coisa bastante simples que seria o que chamamos de módulos básicos ou comuns a praticamente todo sistema de cunho comercial, que seria o cadastro e a parte fiananceira contábil. Além de ser bem mais abrangente.
O custo desse nosso desenvolvimento seria dividido entre os coloboradores e pago com horas de trabalho. A idéia é parecida, mas o escopo diferente.
Um abraço.
Responder
29/09/2004
Dopi
Ola Aroldo, obrigado pela citação....
Decidi fazer o ACBr OpenSource porque ele é mais focado para os desenvolvedores... assim consegui captar ajuda (muito bem qualificada) para um projeto, que se fosse desenvolver sozinho seria muito trabalhoso e difícil de testar...
Sinceramente acredito que se o ACBr fosse comercial, o que eu venderia de copias, não cobriria os ´custos´ de desenvolvimento.... e ainda estaria sujeito a pirataria...., suporte técnico, etc....
Sem falar que um Bug em um programa/componente comercial é motivo pra ´protesto´ dos usuários.... No OpenSource descobrir um Bug é colaborar, participar, ajudar.... ;-)
Estive pensando em fazer um PDV Free, mas não OpenSource para Supermercados... E tentar vender propagandas ou banners, na tela do programa (confesso que viajei na maionese :-) )
Mas, não ví senso prático, ou fundo comercial que justificasse.... usuário dá um trabalho.... ;-)
A ideia do [b:d6c23f0026]amjorge [/b:d6c23f0026] é interessante... mas acho que deveria ser mais modular... como por-exemplo desenvolver um SuperDBGrid, altamente configuravel pelo usuário, com vários recursos.... ou seja, fazer uma coleção de Componentes focados a desenvolvedores de Aplicação Final.... ai sim, tó dentro...
Decidi fazer o ACBr OpenSource porque ele é mais focado para os desenvolvedores... assim consegui captar ajuda (muito bem qualificada) para um projeto, que se fosse desenvolver sozinho seria muito trabalhoso e difícil de testar...
Sinceramente acredito que se o ACBr fosse comercial, o que eu venderia de copias, não cobriria os ´custos´ de desenvolvimento.... e ainda estaria sujeito a pirataria...., suporte técnico, etc....
Sem falar que um Bug em um programa/componente comercial é motivo pra ´protesto´ dos usuários.... No OpenSource descobrir um Bug é colaborar, participar, ajudar.... ;-)
Estive pensando em fazer um PDV Free, mas não OpenSource para Supermercados... E tentar vender propagandas ou banners, na tela do programa (confesso que viajei na maionese :-) )
Mas, não ví senso prático, ou fundo comercial que justificasse.... usuário dá um trabalho.... ;-)
A ideia do [b:d6c23f0026]amjorge [/b:d6c23f0026] é interessante... mas acho que deveria ser mais modular... como por-exemplo desenvolver um SuperDBGrid, altamente configuravel pelo usuário, com vários recursos.... ou seja, fazer uma coleção de Componentes focados a desenvolvedores de Aplicação Final.... ai sim, tó dentro...
Responder
30/09/2004
Amjorge
A idéia de ser Open Source é justamente para tornar esta base, mais confiável. E ainda contar com a colaboração e conhecimento para ir aperfeiçoando.
Responder
30/09/2004
Dopi
Comecei a desenvolver para uso próprio uma Unit que cria um Form com um Grid que pode ser configurado em Run-time.... gravando seu estado em arquivos INI. Nao fiz um componente porque uso internamente....
Mas a ideia básica é montar uma janela de ´Buscar Registro´ que seja totalmente independente do programa e altamente configurável...
Uma vez na tela do Grid o usuário ou técnico entrar em CONFIGURAÇAO e poderá:
- Definir pergunta Inicial para filtro no SQL
- Selecionar os campos/colunas
- Definir coluna inicial do Grid
- Mudar a localização, ou tamanho das colunas
- Mudar Tamanho, Cor da fonte das colunas
- Criar regras (condiçoes) para colorir as celulas , Linhas ou Colunas
- Zebrado ou nao
- Tamanho, posicionamento e Estado do Form na Tela
isso tudo é salvo nos arquivos .INI e .COL mencionados acima. O arquivo .COL usa o DBGrid.Columns.SaveToFile
Agora a proxima vez que o a funçao SQL_GridAcha for chamada, o DbGrid se ajustará de acordo com os arquivos .COL e .INI
O DbGrid tb faz:
- Indexação por clique no titulo da coluna, Crescente/Decrescente
- Busca por qq coluna apenas iniciando a digitação do texto . Indexada se houver indices disponiveis ou Sequencial (podendo interromper) se nao houver inidice. Se TField.Tag = 1 ele cria o indice dinamicamente quando efetuar a busca...
os Indices são criados Localmente usando o CDS. e não reabrindo a Query
No momento a ediçao do SQL deve ser feita manualmente... Estou tentando incorporar o OpenQueryBuilder a essa rotina....
Mas a ideia básica é montar uma janela de ´Buscar Registro´ que seja totalmente independente do programa e altamente configurável...
//////////////////////////////////////////////////////////////////////////////////// Function SQL_GridAcha(CDSUtil: TClientDataset; Tabela, CampoRetorno : String) : Variant ; // Monta Grid de Busca, retorna true se terminou com OK, // ou false se cancelou. // CDSUtil, comtem ClientDataSet que aceite COMMANDTEXT para montar e executar SQL // tambem é utilizado para acessar ARQEXTERNO para recuperar o INI e COL // Tabela, Nome da TABELA a ser consultada. Usada para nomear os arquivos INI e COL, // Ex. se Tabela = ´CLIENTE´, CLIENTE.INI e CLIENTE.COL. Também será usada // em comando SQL inicial ´select * from CLIENTE´. SQL poderá ser ajustado // com outros campos ou Parametros em OPÇõES do SQL_GridAcha // CampoRetorno, Usado em Fieldbyname para efetuar o retorno dessa Funçao ////////////////////////////////////////////////////////////////////////////////////
Uma vez na tela do Grid o usuário ou técnico entrar em CONFIGURAÇAO e poderá:
- Definir pergunta Inicial para filtro no SQL
- Selecionar os campos/colunas
- Definir coluna inicial do Grid
- Mudar a localização, ou tamanho das colunas
- Mudar Tamanho, Cor da fonte das colunas
- Criar regras (condiçoes) para colorir as celulas , Linhas ou Colunas
- Zebrado ou nao
- Tamanho, posicionamento e Estado do Form na Tela
isso tudo é salvo nos arquivos .INI e .COL mencionados acima. O arquivo .COL usa o DBGrid.Columns.SaveToFile
Agora a proxima vez que o a funçao SQL_GridAcha for chamada, o DbGrid se ajustará de acordo com os arquivos .COL e .INI
O DbGrid tb faz:
- Indexação por clique no titulo da coluna, Crescente/Decrescente
- Busca por qq coluna apenas iniciando a digitação do texto . Indexada se houver indices disponiveis ou Sequencial (podendo interromper) se nao houver inidice. Se TField.Tag = 1 ele cria o indice dinamicamente quando efetuar a busca...
os Indices são criados Localmente usando o CDS. e não reabrindo a Query
No momento a ediçao do SQL deve ser feita manualmente... Estou tentando incorporar o OpenQueryBuilder a essa rotina....
Responder
Clique aqui para fazer login e interagir na Comunidade :)
