Développement Compta open-source

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 ?

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

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+

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

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+

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 :
:fleche: http://projets.developpez.com/

;)

Bonjour,

A mon avis, Lazarus présente 2 limites pour l'instant "infranchissables" à moins d'un temps de développement excessivement long [il faut créer ou modifier des composants] :

• les états (reports) : Lazreport est à des années lumière des générateurs de reports "usuels"... Et pas de pdf, or, pour la DGI (Direction Générale des Impôts), chaque année, on doit historiser au format pdf les principaux documents tels que balance, grand livre, journaux... On fait cela comment avec Lazarus ?
• les StringGrids sont "redoutablement" buggés (colonnes invisibles notamment tout à fait inutilisables) et on ne peut pas tout faire en dbGrids.

Bref en Lazarus, c'est un projet très ambitieux. Mais, si quelqu'un a une solution valable pour les 2 écueils ci-dessus, j'en suis...

On ferme les yeux, les Lazaruzien(ne)s :oops: : La suite n'a rien à faire dans ce forum mais comme c'est pour faire une compta "société", cela "m'invite" à une petite disgression dont vous voudrez bien m'excuser :
Maintenant, dans une autre approche, compte tenu du cahier des charges [notamment Linux], si vous voulez bénéficier d'autant d'aide que sur ce forum, et même si vous disposez de temps, JAVA est une alternative qui, à mon avis, permettrait d'arriver à l'objectif en évitant le genre d'écueils cités et dans un temps maitrisable. Il y a certainement d'autres approches possibles... Mais par exemple, je ne tenterais ma chance en C++ justement à cause de la maîtrise du temps : il me semble que les déclarations à la DGI sont annuelles et, partir de rien ou presque, compte tenu de la complexité de la compta et notamment des bornes imposés par les liasses fiscales et autres déclarations... hum, il ne faut pas perdre de temps avec l'EDI, les classes ou/et les composants...

Cordialement. Gilles

Alcatiz,

La question est de savoir si on se limite d'entrée à un projet français ou francophone.

Ce serait certainement plus simple pour commencer, mais peut-être un peu limitatif à long terme.

J'apprécie beaucoup developpez.com pour trouver de l'aide, mais je pencherais plutôt pour sourceforge.net pour l'hébergement du projet, à moins que developpez.com ne soit multilangue...

Rebonjour,

La comptabilité française n'est pas exportable ! Elle est très particulière... et savamment compliquée... J'imagine un Québecois devant une de nos feuilles de paye, nos déclarations de TVA face à un bistrotier belge, nos liasses fiscales au Luxembourg...

Cordialement. Gilles

Gilles,

C'est un vrai problème si on ne peut pas produire des PDF ! Ça parait incroyable comme lacune. Si quelqu'un a d'autres informations à ce sujet ce serait très utile ! Il faudra peut-être, en attendant, produire des fichiers intermédiaires qui seraient transformés en PDF par du Java (ou Python ou autre).

Pour les StringGrids, c'est un peu laborieux, mais j'ai l'impression qu'on peut y arriver. J'ai déjà une saisie d'écritures presque opérationnelle.

A+

Bonjour Martinux,

• Pour les StringGrids, il faudrait retrouver mes Posts : saisir RAS mais pas de colonnes invisibles : elles sont purement "perdues". J'ai également un contournement : chaque StringGrid est associée à une StringGrid invisible mais il faut les synchroniser... et alors le code "opérationnel" a une drôle d'allure. Il y a éventuellement la kGrid mais elle est moyennement ergonomique. Le sujet, la partie métier sont déjà compliqués. Un code aussi simple que possible avec des outils aboutis, complets et fiables me semble nécesssaires.
• pour le pdf, il y a(vait) http://www.est.hi-ho.ne.jp/takeshi_k...pdf/index.html
• mais même pour les états un peu compliqués, l'utilisation de LazReport consomme beaucoup de temps de "contournement" pour obtenir le résultat de fonctions basiques de générateurs "pro"

Cordialement. Gilles

Gilles,

L'internationalisation est effectivement très ambitieuse, mais je crois qu'on ne devrait pas se l'interdire à priori.

Comme indiqué un peu plus tôt, il me semble que ce projet doit avoir, comme la plupart des autres bons logiciels de compta, un module capable de générer à peu près n'importe quel état en totalisant des séries de comptes comptables définies. C'est de toutes façons nécessaire même pour une utilisation franco-française. Ensuite, si on connait les exigences des administrations étrangères, on pourra sans doute produire des états qui les satisferont.

A+

Oui, on peut faire beaucoup de choses. Mais concrètement, je reste persuadé (têtu le bougre !) que l'internalisation sera(it) très difficile : chaque pays a son plan comptable et par delà probablement ses liasses fiscales ou équivalent. "Heureusement chez nous", elles sont limitées (en nombre) :mouarf:, mais en réalité derrière chacune d'elles, il faut définir les regroupements de comptes, les états...

L'enregistrement des opérations comptables, ce n'est pas ce qui prendra(it) le plus de temps... et c'est transposable. Y compris, l'édition des journaux...

Si vous voulez simplement faire une compta qui édite CR et bilan... cela dépend "déjà" du plan comptable... qui est national mais pas international.

Mais, vous voulez une comptabilité pour une société et donc répondre aux obligations de la DGI qui impose ses normes, ses états... et il serait bien que l'ensemble soit automatisé (ie intégré dans le logiciel).

Pour rester optimiste, on peut penser que si on arrive à résoudre le problème pour la compta nationale, il sera difficile de trouver plus difficile et compliqué ailleurs... Mais à contrario (pessimiste), sous Windows, même si les sociétés ont été rachetées pour certaines par des fonds étrangers, Ciel!, Sage... les logiciels n'ont pas été exportés vers d'autres pays en tous cas tels quels : ils sont trop spécifiques au nôtre. Cela mérite réflexion même si cela n'a pas valeur de preuve.

Cordialement. Gilles

bonjour

On peut exporter des rapport LazReport avec le composant lazreportpdf export qui utilise le paquet pack_powerpdf. je vient de faire un test sur ma debian ça fonctionne.


cordialement
claude

Citation:

---

Envoyé par selzig

pour le pdf, il y a(vait) http://www.est.hi-ho.ne.jp/takeshi_k...pdf/index.html

---

le composant existe et se trouve dans le svn de lazarus-ccr. il a même été mis à jour il y a deux semaines

cordialement
claude

Oui, c'est ce que je disais : on peut toujours... mais doucement, pas d'enthousiasme hâtif, lisons la (les) doc(s).

A première vue : cela s'annonce bien...
http://www.lazarus.freepascal.org/in...p?topic=7285.0 [on apprend qu'il est basé sur PowerPdf : http://svn.freepascal.org/cgi-bin/vi.../?root=lazarus --> needs powerpdf 0.9.4 ]

Mais déjà un bémol (c'est devenu un réflexe maintenant : Composant "potentiel"... quels bugs déjà référencés ?]
http://www.lazarus.freepascal.org/in...p?topic=9217.0 [Celui-là n'est pas éliminatoire : en compta, on n'utilise pas trop le code-barre :mouarf:]*

Mais, mais...
http://www.est.hi-ho.ne.jp/takeshi_kanno/powerpdf/. PowerPdf est obsolète et donc non maintenu dit l'article.Y a-t-il un (autre) PowerPdf spécifique à FPC qui est en cours de développement comme semble l'indiquer Pomalo ? Je n'ai pas vu d'annonce à ce sujet, pas de Wiki... Si tel n'est pas le cas, c'est plus ennuyeux et risqué : peut-on développer un logiciel de cette envergure avec des composants non maintenus ? Si le prochain FPC n'est plus compatible avec PowerPDF [cela se pose comme cela puisque seul le premier évolue] et qu'il n'y a pas de solution de secours, le logiciel n'est plus conforme à la législation...

Cependant, on peut contourner le problème : imprimer sur une "imprimante pdf virtuelle"... qu'il faut installer sur Linux... C'est un autre problème mais on peut deviner que cela va compliquer un peu le paquet d'installation...

Bon, je ne vais pas monopoliser cette discussion. Si ce projet démarre, je vous souhaite bon vent. Et si quelqu'un a une réponse [ie pas un contournement] aux "écueils", merci de l'annoncer sur le forum... Cela peut toujours servir.

Et avant de se lancer,
Petite information à vérifier auprès de la DGI : pour que les pièces imprimées par un logiciel de compta soient directement recevables par la DGI, il faut que le logiciel soit agréé par celle-ci. Si tel est le cas, quel est le cahier des charges ? [ http://www.compta-online.com/comptable.html?sujet=10357 ]

*Ce qui me rappelle que sur LazReport (je ne parle pas de l'édition en PDF mais de l'édition "simple"), lorsque j'ai fait les tests [0.9.26.2], il y en avait un bug sur l'EAN13 (un des codes-barre les plus utilisés)... alors pour développer un logiciel de gestion sans édition de codes-barre... c'est "délicat".

Cordialement. Gilles

Comme selzig , ce qui me bloque un peu , beaucoup etc... c'est les bugs récurrents de lazarus surtout que j'attends l'annonce de D2011 prometteuse d'un avenir Linux .

En attendant , j'ai testé moi aussi lazreport et powerpdf avec succès sur une petite appli commerciale (facturation) .

j'ai également été faire un tour sur le wiki de l'April . C'est beau de se lancer dans un dev. mais faut encore voir ce qu'il existe 8O

Bonjour,

Citation:

---

Envoyé par SergioMaster

j'attends l'annonce de D2011

---

Si Delphi 2011 marche bien sous Linux, ça peut changer la donne. Mais pour l'instant on n'en sait trop rien... On peut espérer qu'il ne sera pas trop difficile de réutiliser ce qui aura été fait sous Lazarus.

Citation:

---

Envoyé par SergioMaster

faut encore voir ce qu'il existe

---

J'ai été voir, bien sûr, et j'ai testé de nombreux logiciels, mais dès qu'on creuse on est vite bloqué par plein de problèmes. Aujourd'hui, je n'ai pas de solution et je ne suis pas le seul à le dire.

A+

Citation:

---

Envoyé par martinux

"Si Delphi 2011 marche bien sous Linux, ça peut changer la donne. Mais pour l'instant on n'en sait trop rien... On peut espérer qu'il ne sera pas trop difficile de réutiliser ce qui aura été fait sous Lazarus."

---

A mon avis cela sera différent. Pour le peu qu'on en sache, Delphi utilisera un wrapper QT. Le nouveau Delphi sera donc loin de l'ancien Delphi (au niveau habitudes). Je voulais me faire une idée de Lazarus en QT pendant mes vacances pour voir si cela ressemblait à l'approche utilisée par le développement QT4/C++... et pour voir comment Lazarus utilise QT et ainsi pouvoir situer la concurrence 8-). Je n'en ai pas eu le temps de faire quelque chose de significatif avec mon dépassement de temps pour mes "Animated Gifs" (hormis compiler l'IDE avec l'interface QT)... Mais de toute façon, à mon sens, cela ne ressemblera pas aux habitudes LCL... Bonne discussion d'éminents "Delphinologues" à ce sujet :
http://www.developpez.net/forums/d89...delphi-2011-a/. Cela me semble moins "grave" et plus prometteur que Delphi Prism... et puis le Delphi "compilé" est un produit costaud, je dirais "digne de confiance" autant que Qt qui dispose d'une bibliothèque bien fournie...

Cordialement. Gilles

Un aparté pour les éditions PDF, je travaille pour un revendeur de logiciels Sage. Les éditions pour la DGI, on installait PDF Creator chez les clients avants qu'ils n'intègrent un driver pdf et ils impriment leurs états avec, et les logiciels ne sont pas donnés. Donc le fait de ne pas avoir de composants pour ça ne me parait pas être rédhibitoire.

Bonjour à tous.

J'ai trouvé un nom disponible : gestinux et j'ai créé un projet sur sourceforge.

C'est donc là que peuvent s'inscrire les volontaires...

Il faudra mieux s'exprimer en anglais !

EDIT : Je découvre SourceForge : il faut apparemment me demander de vous inscrire au projet (en donnant votre pseudo sourceforge, obtenu après inscription sur ce site).

A bientôt

Tintinux

Salut,
Il y a déjà comptalinex en espagnol.
J'ai eu du mal à compiler mais il existe un deb
Mais comme trame ça peut donner une idée.
Autrement sous gambas2 il existe laurux.fr une compta excellente

Bonjour,

J'avais essayé de contacter les développeurs de comptalinex, sans réponse à ce jour. Il faudrait qu'il puisse être traduit en français et je n'ai pas vu que les états soient paramétrables pour des exigences non espagnoles (mais je me trompe peut-être, ne parlant pas un mot de cette langue).

Quant à Laurux, il bourré de bugs, je le trouve mal conçu et peu robuste, et il lui manque encore beaucoup de fonctions. Il doit être possible de faire beaucoup mieux, avec un AGL digne de ce nom.

Mes développements avancent, mais j'ai eu moins de temps disponible que prévu. L'importation de données et une saisie d'écritures vont être bientôt montrables, d'ici mi-juin j'espère.

Cordialement,
Tintinux

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.

Pas trop de soucis non plus avec LazReport et l'exportation en PDF est parfaite. Le designer de report est toutefois un peu pénible et plante très souvent sous Linux, mais apparemment marche mieux sous Windows. Pas moyen non plus de faire marcher les fonctions utilisateur.

J'ai fait un module qui, en faisant utiliser le designer de LazReport par l'application devrait permettre de concevoir des états fiscaux pour un grand nombre de pays.

Ce qui m'a le plus ennuyé a été l'impossibilité de faire hériter des Form d'un ou plusieurs modèles, comme je faisais autrefois avec Delphi. On a des erreurs imprévisibles en lisant les dfm. Les TFrames ne sont pas non plus parfaites, et leurs événements doivent être assignés par code, ou sinon se perdent...

Le bilan est donc positif pour Lazarus, même si la version 0.30 ou 1.0 est attendue avec impatience !

En l'équivalent d'un mois à plein temps, passé surtout à tester différents composants et fonctionnalités, j'ai une petite comptabilité presque opérationnelle pour une TPE. Il y a évidemment encore beaucoup à faire, mais comme je démarre un nouveau boulot, je vais devoir y passer beaucoup moins de temps.

J'ai une demande pour continuer sur des fonctions ventes et achats, afin de remplacer un petit ERP dans une PME, mais je ne peux pas la satisfaire. Elle pourrait pourtant être rémunérée. Avis aux amateurs !

Bonjour Tintinux,

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

Citation:

---

Envoyé par tintinux

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" ? :lol: 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