Discussion :

[tintinux]

Bonjour,

Je suis passé sous LINUX il y a quelques temps, je dois faire la compta de ma petite société... sans le secours de Windows.

J'ai cherché des Compta ou Erp disponibles sous Linux et il y en a peu. J'ai évalué Laurux, OpenSi et surtout OpenErp. Les deux premiers sont des développements assez solitaires, non opensource, dans des langages exotiques, et comportent pas mal de défauts de conception.

OpenErp est un énorme monstre qui serait prometteur... mais à peu près aucune fonction de base de marche correctement. Il est excessivement complexe à paramétrer et installer, comme tout ERP qui se respecte. On ne peut pas s'en sortir sans un support payant, la communauté n'aide pas.

Comme j'ai un peu de temps, j'ai donc envie de me lancer dans le développement d'une petite compta opensource, avec à terme un peu de gestion. Je crois que j'y passerai finalement moins de temps qu'à debugger OpenErp... et ça peut faire une bonne référence pour Lazarus.

Est-ce qu'il y a des gens qui ont eu la même idée, ou que ça intéresserait d'y participer ? Il faudrait disposer de temps et de quelques compétences, surtout fonctionnelles...

Qu'en pensez vous ?

[SergioMaster]

Il est possible que je sois interressé , quoique la compta n'ai jamais été ma tasse de thé , c'est vrai qu'un offre Opensource Linux ferai du bien a ce dernier

[tintinux]

Sergio,

Il y a des choses qui peuvent être faites sans trop connaître ou apprécier le métier, et qui nécessitent de bonnes connaissances techniques.

Il faudra, par exemple :

Un générateur de rapports paramétrable, pouvant écrire le total de séries de comptes comptables données à des positions données d'une page. Cela permettrait de produire des bilans, comptes d'exploitation et divers états fiscaux. Il devrait idéalement être paramétrable en mode graphique.

Un importateur de données paramétrable, acceptant des champs dans n'importe quel ordre et des sources et formats variés, quelques règles de conversion, le tout pouvant être défini de manière très visuelle.

Et puis, il faudra aussi soigner les procédures d'installation. Il faut qu'il y ait une installation quasi-automatique, avec sous Linux des paquets deb et/ou rpm, ce que je ne maîtrise pas encore.


A+

[pomalo]

bonjour

je veut bien te donner un coup de main je sais faire des paquets deb (j'en ai fait pour une application lazarus pour mon boulot qui utilise une base de données mysql avec creation et base et table. ) les rpm j'en ai fait ya longtemps mais j'e veut bien me repencher dessus.
je veut bien donner un coup de main au niveau développement mais je connait pas grand chose à la compta.
Ca fait un moment que je cherche un logiciel de compta opensource leger pour des associations.

a bientôt
Claude

[tintinux]

Pour les deb, je suis preneur !
Je crois qu'on sera dans la même configuration qu'à ton boulot, avec MySql.
Pour les rpm c'est moins urgent, je crois que nous sommes de plus en plus nombreux sous Ubuntu, ou au moins Debian.
A+

[Alcatîz]

Bonjour,

Une petite page de publicité : si une équipe se met en place et si le projet se concrétise, Developpez.com dispose d'une solution complète clé en main entièrement gratuite :
http://projets.developpez.com/

[Invité]

Bonjour Tintinux,

Merci pour votre CR mais je comprends mal certains de vos propos. Un déni de bug ? Question d'interprétation ?

Voici quelques nouvelles et un premier bilan :
Aucun problème avec les StringGrid en 0.28.2, quoi qu'en dise selzig. Certes, des colonnes invisibles et un événement de validation de cellule seraient appréciables mais cela ne justifie pas à mon avis l'utilisation d'une version instable.

En 0.9.28, les StringGrids sont buggées ! C'est un fait que j'ai pris la peine de vérifier avant de le ré-écrire... [J'ai installé la dernière 0.9.28 alors que je ne me sers plus de ces versions]. Maintenant que vous ne vous serviez pas de la fonction que j'évoque, tant mieux... Mais en quoi la non-utilisation de la fonction de visibilité des colonnes peut-elle relativiser ce bug ? Il faut rester pragmatique. Il y a bug ou pas bug : si "Aucun problème... quoi qu'en dise selzig"... alors pas bug ! Et pourtant, je maintiens qu'avant la 0.9.29, si votre StringGrid possède X colonnes dont Y déclarées invisibles, le code affiche les X-Y premières colonnes de la StringGrid et ceci quelque soit le N° des colonnes déclarées invisibles...

En quoi la non-utilisation de la fonction de visibilité des colonnes peut-elle relativiser ce bug ? La réponse semble être dans la suite de vos propos : "Certes, des colonnes invisibles [...] seraient appréciables". Evidemment vu ainsi... Justement en 0.9.28, cette fonction est implantée sur les colonnes... et buggée. Mais, puisque les colonnes invisibles ne fonctionnent pas, elles "disparaissent" ? Donc, en élargissant grossièrement le propos : il n'y a pas de problème parce que tout ce qui ne fonctionne pas, n'existe pas... et donc, "évidemment", à ce titre, ne peut pas poser de problème... CQFD. Avec un tel angle d'attaque, je ne peux que souscrire à votre conclusion.

En attendant avec la 0.9.28, on peut contourner le problème évoqué, par exemple comme je l'avais fait en associant une StringGrid.visible := false; à la StringGrid initiale dont toutes les colonnes seront visibles (puisqu'on ne peut pas en rendre invisibles). Après c'est un choix. Il faut déterminer et évaluer l'impact d'une telle solution de contournement. En ce qui me concerne, le codage de la couche métier me semble souvent suffisamment compliqué...

Ce qui m'amène à ne pas partager non plus -décidément c'est beaucoup de contestations pour 2 phrases citées- votre assurance quant à l'emploi "obligatoire" d'une version stable... D'abord, il y a là une "interprétation linguistique" toute Lazarusienne que j'ai eu un peu de mal à comprendre lorsque j'ai découvert Lazarus. Mais en réalité, il faut "entendre" que seule la 1.0 sera stable... et encore quand on voit le postulat de départ, on peut en douter... (et tant mieux). Le reste, c'est du beta. La 0.9.28 est la dernière évolution de la version de développement 0.9.27 qui n'a jamais existé réellement avec cette appellation... Elle ne représente qu'un aboutissement d'un cycle de développement en cours... (alors qu'un autre, le suivant est déjà en projet). Le code est alors en effet "stabilisé" (et non pas stable) dans son développement et... dans ses erreurs. C'est très déroutant au départ. Ainsi, les 0.9.26, 0.9.28 bâties conceptuellement grosso-modo sur le même Grid.pas n'ont pas permis de corriger le problème des colonnes invisibles. Un nouveau cycle de développement a permis de réécrire de manière importante les "ancêtres" nécessaires à cette correction.

Alors évidemment, utiliser une version stable m'a paru au départ plus rassurant et habituel... et efficace. Je l'ai écrit plusieurs fois dans ce forum. Et j'ai changé d'avis pour 2 raisons :

• Depuis la 0.9.29, je développe "normalement" avec des StringGrids, le normalement signifiant "tel que l'on peut l'attendre du cahier des charges de la fonction invisible des colonnes" par exemple. Si j'attends la future "stable" (la 0.9.30), en "conservant" la 0.9.28, je reste avec des StringGrids buggées, amputées de fonctionnalités qui nécessitent, pour être utilisées, un code de contournement qui impacterait tellement fortement mon développement (tenant compte du bug) qu'il ne sera pas réversible... au point qu'il faudra totalement le ré-écrire avec une 0.9.30 ! Donc, ce cas est typiquement un contre-exemple de productivité avec l'utilisation d'une version stable. Je ne dis pas que c'est généralisable... Mais cela peut ébranler quelques certitudes...
• De plus, utiliser les dernières releases me permet de participer modestement mais constructivement au développement de Lazarus. Je teste, je signale, je propose quand je le peux. Je rouspète également... en utilisant le canal privé du bug tracker.

A chacun d'adapter sa pratique donc... Mais utiliser une version de développement non "stable" ne doit pas être éliminé d'un simple trait de plume... ou être présenté comme un non-sens, une hérésie...

Au final, j'apprécie énormément Lazarus : c'est un projet extrêmement ambitieux et sympathique. Mais, sans aucune polémique, quelque soit cet attachement, un bug est un bug et doit être signalé comme tel. Il est acceptable ou non. Chacun choisit. On sait (ou on peut) le contourner ou pas... In fine, cela reste un bug qu'il faut corriger sinon, à terme, l'ensemble devient incohérent et peu praticable... Et par soucis de maintenir des sources d'information fiables, il ne doit être ni minimisé (c'est la mauvaise interprétation sans doute dont je parlais au départ et dont je veux ici simplement supprimer l'équivoque), ni maximisé (j'espère que je n'ai pas donné cette impression), mais simplement signalé.

Bon WE.
Cordialement. Gilles