Array
(
)

Projeto PAI de aplicações diversas

Amjorge
   - 29 set 2004

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.


Aroldo Zanela
   - 29 set 2004

Colega,

Você conhece?

Projeto Automação Comercial Brasil
http://acbr.sourceforge.net


Amjorge
   - 29 set 2004

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.


Dopi
   - 29 set 2004

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 amjorge é 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...


Amjorge
   - 30 set 2004

Como seria este Super DBGrid por exemplo que você citou ?


Amjorge
   - 30 set 2004

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.


Dopi
   - 30 set 2004

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...

#Código


////////////////////////////////////////////////////////////////////////////////////
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....