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,

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

[tintinux]

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

[Invité]

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

[tintinux]

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+

[Invité]

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

[tintinux]

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+

[Invité]

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) , 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

[pomalo]

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

[pomalo]

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

[Invité]

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 ]*

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

[SergioMaster]

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

[tintinux]

Bonjour,

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.

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+

[Invité]

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

[thierrybo]

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.