| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | Por acaso este é daquele género de programas que de vez em quando me perguntam se conheço.
Agora já posso dizer que conheço um que é Português e em GPL.
Parabéns pelo vosso trabalho e pela coragem de terem usado GPL...
|
| |
| |
| | Pronto, eu esperei e esperei e ninguém o disse... Vou mesmo ter de ser eu:
Costumam perguntar-te «Ó Evaristo, tens cá disto?»
Pronto. *respira fundo*
«You cannot steal a gift, which is what code released under the BSD license is.» |
| |
| | Engraçado que muitas das empresas dizem que não colocam os seus produtos sobre a licença GPL porque vão perder dinheiro, ou vão perder a sua vantagem tecnológica..... infelizmente ainda não ouvi dizer que alguma empresa usou este software pare desenvolver o seu.... certo ???
Será que as empresas que querem usar este software fazem download ou compram ????
Gostaria de saber qual o racio de vendas Vs Download.
(())
Esqueleto
|
| |
| |
| | Sinceramente, um ERP é justamente uma daquelas áreas onde me parece que a vantagem de ser código fechado para os desenvolvedores é menor. Isso porque não se pode em geral usar um ERP "chave-na-mão".
Não conheço nenhum ERP que possa ser utilizado numa instituição sem adptações (e não são geralmente muito pequenas) ao caso em particular que é aquela empresa.
Ou seja, alguém vai ter de fazer essa adaptação - e quem melhor para isso que alguém que conheça o código?
Claro que pode-se pensar que podem existir outras empresas que peguem no código e forneçam eles o serviço de adaptação do ERP às necessidades da empresa... Mas ainda assim não creio que os desenvovedores originais percam com isso, porque estão na posição de maior visibilidade.
Cumps, JB |
| |
| | - Sistemas instalados a pedido do cliente (pagos): 3
- Downloads efectuados a partir da sourceForge desde Novembro: +/- 150
Conclusão #1: por cada cópia legal vendida há 50 cópias piratas? Conclusão #2: a coisa está tão mal que nem conseguem instalar para testar? Conclusão #3: o director de marketing da M.P. deveria ser despedido? Conclusão #4: desiste e 'alista-te' na M$? Conclusão final: mais 6 meses e arrisca-se a ser um caso sério! Comentário + sério: pela experiência que tenho, se a ideia é verdadeiramente original e válida (pelo menos em aplicações desta dimensão), não vale a pena 'fechar' o código - mesmo estando disponível, ninguém tem a pachorra para o 'descascar' ;-)
e, se a tiver, melhor... sempre pode dar uma ajuda ;-)
|
| |
| | Há ainda a hipótese dos que fazem o download para "investigar", ou seja, ver o que faz o programa, talvez mesmo ponderar a compra. Penso que essa é uma vantagem--a possível adaptação ao programa antes da eventual compra (e não apenas neste caso.)
«You cannot steal a gift, which is what code released under the BSD license is.» |
| |
| | | Conclusão #2: a coisa está tão mal que nem conseguem instalar para testar?
Epá eu fiz o download para experimentar (só por curiosidade) mas aquilo começou a queixar-se que faltava uma "class" e que o parametro Xint não é válido, como o meu interesse era apenas por curiosidade para ver a maturidade do projecto, etc (para que o possa vir a aconselhar ou não), não perdi mais tempo com isso!
Ok, eu admito que sou um bocado alérgico ao Java o que fez com que arrumasse o caso ainda mais depressa!
Aqui vai o log:
+ java -Xint -classpath /usr/share/pgsql/pg73jdbc3.jar:/usr/local/m16e/lib/m16e-free-tools-v0r7.jar:/usr/local/m16 e/lib/evaristo-v1r2.jar com.m16e.mpbiz.MpBiz '\'
Error: Unrecognized JVM specific option `-Xint'.
Couldn't find or load essential class `java/lang/Object' java.lang.NoClassDefFoundError java/lang/Object
./evaristo.sh: line 29: 3891 Aborted (core dumped) java -Xint -classpath $MPBIZ_CLASSPATH com.m16e.mpbiz.MpBiz $1 $2 \\
Só mais uma coisa, na documentação diz que se pode instalar onde quiser, mas quando ele arranca vai procurar ficheiros sempre a "/usr/local/m16e/evaristo
"Se um dia, a vida te der as costas... apalpa-lhe o cu." |
| |
| | E podes instalar onde quiseres... não quer dizer que execute na mesma :P
---
Conformity is the jailer of freedom and the enemy of growth.
--John F. Kennedy |
| |
| | | Basta substituir a JVM pela da Sun ou da Blackdown e vais ver que funciona ;-) Na documentação tb diz como se pode parametrizar para o correr a partir de outro directório, mas é muito mais fácil instalá-lo no '/usr/local/m16e' -- Read The Fine Manual ;-)
|
| |
| | Kaffe Virtual Machine
Copyright (c) 1996-2002 Kaffe.org project contributors (please see
the source code for a full list of contributors). All rights reservced.
Portions Copyright (c) 1996-2002 Transvirtual Technologies, Inc.
The Kaffe virtual machine is free software, licensed under the terms of
the GNU General Public License. Kaffe.org is a an independent, free software
community project, not directly affiliated with Transvirtual Technologies,
Inc. Kaffe is a Trademark of Transvirtual Technologies, Inc. Kaffe comes
with ABSOLUTELY NO WARRANTY.
Engine: Just-in-time v3 Version: 1.0.7 Java Version: 1.1
Configuration/Compilation options:
Compile date : Fri Sep 6 18:53:01 CEST 2002
Compile host : hp6.mandrakesoft.com
Install prefix: /usr
Thread system : unix-jthreads
CC : gcc
CFLAGS : -O3 -pipe -mcpu=pentiumpro -march=i586 -ffast-math -fno-strength-reduce -O2 -Wall -Wstrict-prototypes
LDFLAGS :
ChangeLog head: Tue Jul 02 11:01:52 PDT 2002 Jim Pick
Isto é o que eu tenho, vinha com o Mandrake, como tenho ideia que dá um trabalhão do caraças instalar o JAVA e configurálo para que fique como deve de ser, fico-me por aqui.
Obrigado pela ajuda, quando tiver um pouco mais de tempo livre tento outra vez ;).
"Se um dia, a vida te der as costas... apalpa-lhe o cu." |
| |
| | Kaffe Virtual Machine
...
Isto é o que eu tenho, vinha com o Mandrake, como tenho ideia que dá um trabalhão do caraças instalar o JAVA e configurálo para que fique como deve de ser, fico-me por aqui. Instalar o Java em linux é facílimo. Vê em http://java.sun.com/j2se/1.4.2/jre/install-linux.html, estão lá as instruções detalhadas. Nota: recomendo a instalação binária versus o '.rpm'! Depois é só acrescentar o directório onde foi instalado o Java ao início da PATH. Eu costumo acrescentar este script no directório /etc/profile.d/: # JVM defenitions
# Author: carlos __ at __ m16e.com
JDK_HOME=/usr/local/j2sdk1.4.2
export JDK_HOME
JAVA_HOME=$JDK_HOME
export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH
export PATH
P.S.: se precisares de ajuda, diz ;-)
|
| |
| | Basta substituir a JVM pela da Sun ou da Blackdown e vais ver que funciona ;-)
Tanto o JVM da Sun como a da Blackdown são (tanto quanto sei e se as coisas não mudaram recentemente) não-livres.
Não sou entendido em Java e daí a pergunta: É possível correr o Evaristo sem recorrer a software não-livre?
P.S. Parabens pela iniciativa!
Ruben |
| |
| | Tanto o JVM da Sun como a da Blackdown são (tanto quanto sei e se as coisas não mudaram recentemente) não-livres. Continuam não-livres :-( Não sou entendido em Java e daí a pergunta: É possível correr o Evaristo sem recorrer a software não-livre? Não. Há dependências da versão 1.4 e, que eu saiba, essas são as únicas JVM que suportam essa versão. Um dia...
|
| |
| | Aqui seguem algumas sugestões que me parece importantes, mais uma opiniõe pessoais:
- Sigam o modelo de exemplo do PHC. É, actualmente, a melhor aplicação do género e, se tiverem pelo menos 3/4 das features deste, já têm um excelente programa;
- Não disponibilizem o manual a versões não pagas. Os clientes que pagam têm de sentir que valeu a pena pagar, houve vantagem nisso. Não só o suporte, mas o manual também seria importante.
- Integração com bases de dados é fulcral. Embora seja ainda uma aplicação pequena, este é um pormenor fundamental.
- Os botões que usam na aplicação não são suficientemente explícitos. Que tal botões mais agradáveis ah vista :-) ?
Obviamente que a lista de críticas (construtivas ;-) e sugestões seria interminável. Não obstante, os meus sinceros parabéns pela coragem, pelo esforço e pelo resultado!
Dominus vobiscum |
| |
| |
| | 3/4 da funcinonalidades do phc é, numa fase inicial exigir demais, se não mesmo o impossível! o PHC é um software extremamente vasto, com n+1 funcionalidades!
Na minha opinião o melhor é mesmo começarem por ter uma boa base (que acaba por ser o que secalhar a maior parte das pequenas empresas utilizam...), mas principalemente uma base que seja escalável, para poderem desenvolver novas funcionalidades apartir dali, de preferência a pedido de empresas!
|
| |
|
| | | 1. Há uma regra que presidiu (e preside) à elaboração da estrutura de dados do MP-Biz, do qual o Evaristo é o primeiro componente:
Não há duplicação de informação, a fim de eliminar grande parte dos erros mais chatos, mesmo que isso obrigue a algumas queries um pouco mais complexas (mas é para isso que inventaram o SQL). Isto significa que não iremos colocar o nome dos clientes nas linhas das facturas, por muito que isso nos simplifique as listagens ;-) 2. Mas porquê? 99% dos utilizadores não lê o manual... 3. ??? (não percebi) 4. Aceitamos (e agradecemos) propostas para novos botões ;-)
|
| |
| | Nomes de clientes nas linhas de facturas?!
Alguém faz isso?!
Se sim, por favor digam-me quem!
Cumprimentos
|
| |
| | | Não aponto que é feio. mas basta olhar para as estruturas de dados (e grande parte ainda são dBase -- é fácil de encontrar essas coisas).
|
| |
| | toda a gente que se apercebe que é muito mais importante as facturas serem mais rápidas do que integridades desses dados estáticos com a base de dados...
isto para bds grandes. acho que vi a efacec a falar nisto...
---
Que Bush vos abençoe. |
| |
| | Para esclarecer algumas dúvidas relativamente à colocação ou não do nome do cliente na factura aquando a sua emissão, convém considerar que uma factura é um "objecto" totalmente autonómo. Após a sua criação, deve possuir todos os valores para que possa ser impresso hoje ou daqui um ano sem adulteração ou falta dos dados iniciais.
Assim é importante que no documento fique referido o nome que o cliente usou naquela factura.
No entanto, e por uma questão de normalização de base de dados, nós optamos por não colocar o nome da tabela mas sim, fazer referência à tabela de entidades (clientes) a uma versão especifica. Assim, no documento temos ClienteID que aponta para a tabela de Entidades que aí contem todos os clientes (e todas as suas alterações).
A vantagem de ter o histórico activo de alterações de clientes é que permite facilmente saber quais as alterações já realizadas, e como a versão mais actual do cliente está marcada, sabemos exactamente qual a que deve ser usada em novos documentos.
Este é o método que nós (eu) uso, é óbvio que existem várias outras maneiras.
Este comentário foi publicado ao abrigo dos conselhos "How to handle a Troll". |
| |
| | | Sem dúvida que essa é uma boa solução, mas o problema só ocorre quando é necessário emitir 2ªs vias de um documento, cuja entidade entretanto alterou a morada (se fôr o nome a ser alterado, deverá ser criada uma nova Entidade). Por enquanto, ainda não está implementada nenhuma solução para essa questão -- que tb não é frequente, mas será assim que fôr possível, à custa de um histórico de alterações ou doutra maneira qualquer...
|
| |
| | se fôr o nome a ser alterado, deverá ser criada uma nova Entidade
Não propriamente. Vêm-me agora à ideia uma empresa aqui da zona que alterou o nome mas *manteve* o NIF, assim sendo no nosso sistema bastou apenas actualizar o nome e também assim manter o NIF bem como o número de cliente por nós atribuido!
O resultado é que tudo que está para trás se mantém como antigamente, e o todos os documentos novos assumem o novo nome.
Cumprimentos,
Este comentário foi publicado ao abrigo dos conselhos "How to handle a Troll". |
| |
| | | Sim, OK! Faz sentido, desde que mantenha o NIF. Mas isso é uma questão que depende mais das conveniências do utilizador (continuar a usar a mesma entidade ou não), do que do desenho da aplicação e aí já se fala em costumização. Tudo menos colocar dados do cliente na tabela das linhas dos documentos para facilitar listagens ;-)
|
| |
| | Nomes de clientes nas linhas de facturas?!
Sim.
Alguém faz isso?!
Sim, por exemplo a PHC!
Cumprimentos,
Fernando Silva
Este comentário foi publicado ao abrigo dos conselhos "How to handle a Troll". |
| |
| | Quanto ao manual, discordo dessa taxa dos 99%. Pelo menos os manuais que acompanham o PHC e que eu já vi (e tenho) são extremamente importantes para a correcta utilização avançada do programa. Claro que para adicionar uma factura não é preciso consultar o manual, mas quando o projecto se tornar grande, é apenas mais uma sugestão para valorizar o vosso investimento :-)
Relativamente ao ponto 3, refiro-me a integração personalizada com qualquer base de dados. Pelo que percebi esse ainda não era um campo muito explorado, mas posso estar redondamente enganado!
Dominus vobiscum |
| |
| | | 3. Iremos procurar mantermo-nos agnósticos em relação às Bases de Dados, pelo que optámos por usar o princípio do máximo denominador comum e, tanto os tipos de campos das tabelas como as procedures e constraints utilizadas se resumem àquelas que são comuns à maior parte das BD. (do Manual do Utilizador)
Antes de instalar a aplicação deverá assegurar as seguintes condições: - Instalação da Máquina Virtual Java (Java Runtime Environment 1.4, ou superior)
- Base de Dados que suporte transacções e stored procedures
- Driver JDBC Tipo II (ou superior)
É claro que, se alguma instalação o aconselhar poderemos optar por fazer optimizações em função da BD a usar, mas aí o cliente corre o risco de ficar 'preso' a essa BD, situação que só será justificável em projectos de grande envergadura.
|
| |
| | é uma boa solução.
já agora, que bds testaram?
e uma dúvida, alguém... a linguagem dos stored procedures não depende da bd? se não, algum linkizinho interessante era bom ;)
---
Que Bush vos abençoe. |
| |
| | | A infraestrutura de ligação às BD's já foi testada com DB2, Oracle, Pointbase, PostgreSQL, SQL Server e SyBase, com o Gaudí, que foi a aplicação utilizada para desenhar a estrutura de dados. As stored procedures do MP-Biz são tão básicas que todas as BD's as devem suportar, eventualmente com algumas alterações, como é habitual no SQL :-(
|
| |
| | Não há duplicação de informação, a fim de eliminar grande parte dos erros mais chatos, mesmo que isso obrigue a algumas queries um pouco mais complexas (mas é para isso que inventaram o SQL). Isto significa que não iremos colocar o nome dos clientes nas linhas das facturas, por muito que isso nos simplifique as listagens ;-) Não sei se te ocorreu isto quando pensaste em evitar a duplicação de informação, mas nota que muitas vezes a duplicação de informação se faz para manter a consistência dos documentos com o momento em que foram emitidos. Por exemplo, se um cliente mudar de nome ou de endereço, vais mudar nos documentos do passado sabendo que na altura o nome ou endereço antigo é que era o certo? Não me parece que seja boa ideia e nem sei se legalmente seria aceitável.
|
| |
| | Tens toda a razão, num outro comentário expliquei o método que uso (pró caso de ser util para alguém) :)
Este comentário foi publicado ao abrigo dos conselhos "How to handle a Troll". |
| |
| | Viva!
em primeiro lugar parabéns pela iniciativa, e desejo felicidades para o vosso projecto!
Em segundo, tenho uma dúvida, pelo que vi o osso software permite emitir facturas, guias de remessa... que são documentos que já têm validade fiscal, o software para fazer isto tem que estar licensiado de alguma forma pelo ministério das finanças?
|
| |
| |
| | | Tanto quanto sei, e a menos que a legislação tenha sido alterada, não está previsto qualquer tipo de homologação da parte do Ministério das Finanças ou qualquer outro. A responsabilidade cai, assim, sobre a entidade que emite esse(s) documento(s) e não sobre a aplicação que o(s) emitiu. Por favor, corrijam-me se estiver enganado ;-)
|
| |
| | penso que sim... mas se não garantirem aos clientes o correcto funcionamento estou a ver aí potênciais bloqueios à utilização...
e ainda não disse, boa sorte.
---
Que Bush vos abençoe. |
| |
|
| | A responsabilidade cai sobre a entidade que emite a factura mas repara que qualquer software que se encontra à venda no Continente tem algo do genero "Compativel com a legislação portuguesa".
Seria um ponto interessante de melhoria e que não me parece demasiado complicado.
|
| |
| | qualquer software que se encontra à venda no Continente tem algo do genero "Compativel com a legislação portuguesa" A M.P. não dispõe de recursos finenceiros que lhe permitam contratar um consultor jurídico a fim de assegurar a veracidade de uma informação desse género e com um grau de responsabilidade tão abrangente :-( No entanto, espero que, se alguém detectar alguma falha legal no MP-Biz nos informe (para que a possamos corrijir) em vez de nos denunciar às autoridades ;-)
|
| |
| | Isto é o que eu acho:
O compatível com a legislação portuguesa, quase certamente se refere a taxas, impedimento que se façam algumas ilegalidades (como apagar facturas sem deixar rasto), etc;
Nas finanças, o que me foi dito, é que para se poder usar um programa de gestão, esse programa deve obrigatóriamente imprimir o texto "Processado por computador" nos documentos emitidos;
O que ouvi dizer mas nunca cheguei a saber se sim ou não: o programa tem de ser registado nas finanças para poder ser usado.
Agora, isto é tudo muito bonito, e ainda hoje pode ser facilmente aplicável, mas daqui por uns anos, quando talvez o open-source for rei cof cof, não faz sentido nenhum.
De qualquer das formas, sugiro que quanto tiveres disponibilidade faças uma deslocação à repartição de finanças mais próxima :)
---
Conformity is the jailer of freedom and the enemy of growth.
--John F. Kennedy |
| |
| | O compatível com a legislação portuguesa, quase certamente se refere a taxas, impedimento que se façam algumas ilegalidades (como apagar facturas sem deixar rasto), etc;
Qualquer programa de gestão/facturação é suficiente flexível para permitir, om mais ou menos esforço, apagar ou anular facturas (ou outros documentos), alterar datas/numerações etc, etc... enfim coisas do dia a dia das empresas :-)
O que ouvi dizer mas nunca cheguei a saber se sim ou não: o programa tem de ser registado nas finanças para poder ser usado.
Era realmente a ideia que eu tinha, e acho que até tem que se pagar para o software ser certeficado ou homologado (ou o que é que quer que eles chamem...) pelo ministério das finanças. O que realmente no caso do software ser gratuito não faz grande sentido, uma empresa estar a pagar só para poder destribur o software dela...
|
| |
| | | F.U.D. ;-) Isso (a homologação) só é necessário para transacções financeiras on-line, e não é feita junto do Ministério das Finanças, mas sim junto das entidades que garantem a transacção: SIBS, Unicre, etc. e, sim! custa uma pipa de ma$$a.
|
| |
