bidossessi

on fera probablement comme ca, mais j'aimerai juste recentrer le débat en rapellant qu'on est encore au stade de définir les fonctionalités de base du soft. completez la liste du premier post avec les éléments relatifs à la gestion des stocks que vous jugez utiles et qui n'y figurent pas. on boucle les suggestions demain midi. de la, on passe à la discussion sur les architectures, etc... il va peut-être nous falloir un trac... je vais voir si je peux utiliser mon compte buildservice chez novell, mais je ne suis pas sûr.

loool, forker quoi? tu connais des soft de gestion des stocks opensource non-web sur le marché? c'est bien ça le problème. et puis je pense qu'un projet bien à nous, ç a vaut la peine d'être entrepris.

je neparle pas de prix. la gestion des stocks dit: openstock: il te reste 30 crayons dans ton magasin. il va falloir en racheter. toi: mince, les gaspilleurs! alors chez qui on les prend? openstock: voila les derniers chez qui on a achété des crayons: A,B,C toi: ah ouis, je me souviens de A, type sympa, le quel j'ai préféré la dernière fois? openstock: tu as préféré C, il avait demeilleurs prix, et il permettait les traites. toi: ouais bon, je crois qu'on va reprendre son bon de commande. openstock, reafis le bon de commande à C openstock: ok toi: mais qui s'amuse à me vider les crayons comme ça? openstock: mahmoud en a pris 25 dans les deux derniers mois. toi: quoi??? ce salopard! attend que je l'attrape! openstock: tu veux voir l'evolution des stocks de crayons dans l'année? toi: tiens, oui. openstock. alors il y a une sérieuse chute au mois de juin. toi: mais pourquoi tous les crayons disparraissent au mois de juin?... bon, on en reparlera après; mets-moi ce rapport en fichier joint dans mon email, je monte chez le boss. il nous reste des boissions fraiches? etc...

d'après mon comptable, le service des moyen emets des bon de commande qui sont transmis avec les bons de réception/sercvie fait à la comptabilité. la fiche fournissuers dont j'ai parlé est juste pour pouvoir trouver rapidement indexer les produits par fournisseur (tel produit disponible chez A, B, C) ou tracer l'historique des fournisseurs (on acheté A,B,C chez tel, et on a été content/pas content de C)

le cadre du soft définit les fonctionalités qu'il doit assurer. ce n'est pas outil CRM. c'est un outil de gestion des stocks. il pourra être couplé à un outil CRM ultérieurement si le besoin se fait sentir, donc, pas de gsetion commerciale. la gestion des moyens généraux est un secteur assez vaste, c'st vrai, mais pas tant que ça.

je suis content de voir l'engouement du forum pour un vrai projet communautaire opensource avec des applications potentielles dans le monde professionel. Alors pour répondre à certaines question: les etapes sont claires, et nous en sommes à la première: cahier de charges le plus complet possible. par rapport aux éléments de construction du soft: j'ai choisi mon env de développement habituel: python/GTK/sqlalchemy/reportlab, mais ces choix restent évolutifs. en fonction de la discussion sur ce forum, on verra ce qu'il convient de choisir au final; ce qui permet au plus grand nombre de pouvoir participer et s'exprimer; mais deux choses doivent rester constantes: GPL(v2 ou 3, à nous d'en discturer) et multi-plateforme. cette discussion est cependant prématurée. l'urgence maintenant des de nous mettre d'accord sur les fonctionalités du soft. De là, une groupe de développeurs pourra se déclarer et prendre les choses en main. par rapport aux fonctionalités du soft l'objectif de ce soft au jour d'aujourdh'ui est purement la gestion des stocks. - il est destiné aux entreprises qui souhaitent pouvoir informatiser leur gestion de stock, sans distinction de type. il doit donc gérer de façon assez générale pour pouvoir convenir au plus grand nombre. - Pour ceux qui les connaissent, il espère être une alternative opensource viable aux produits SAGE/DLG (ça c'est de l'ambition! mais on le peut, alors pourquoi pas?) - la gestion commerciale n'est pas dans ses prérogatives. mais l'évolution vers un tel produit est possible si la communauté le désire. je tiens cependant à ne pas perdre de vue le but original du projet: les stocks lorsque ce projet aurra atteint une vitesse de croisière, on séparera le topic en sous catégories: UI et logique

je sais que le stockage de procédures est possible avec mysql ou postgres, mais pas sous sqlite à ma connaisance. et puis si les fonctions de transactions sont stockées séparement , ça simplifie peu-être le problème. changer pour changer, je préfererais toucher quelques lignes de pyhon pour garder la possibilité de travailler avec plusieurs db différentes, ce qu'offre sqlalchemy. mais bon, on est loin de l'ordre du jour là pas de suggestions supplémentaires?

...pour faciliter la virtualisation sous windows. c'est un geste important. peu-être un changement de politique après les campagnes de diabolisation de FOSS?

Alors, à votre avis, quelles fonctionalités doivent figurer dans un logiciel de gestion des stocks de qualité corporate?

on va probablement utiliser l'ORM python-sqlalchemy pour la db, pour simplifier le mappage attributs-colonne. il supporte les majeures DB y compris SQlite, sur lequel je ne sais pas du tout si les procedures sont possible, et je pense q'un backend SQLite sera une option du soft.

je suis ravi de te voir prendre inteêt à ce projet. python n'est vraiment pas difficile à maitriser, si le groupe qui se forme décide d'y rester, bien sur. mais même si tu ne veux pas coder, tes conseils seront j'en suis sur, précieux.

c'est vrai que c'est vaste comme domaine, mais qu'est-ce qui est faisable ici, maintenant? vu que le CPL est déjà une réalité en algérie, et que plusieurs gadgets domotiques sont basés sur cela (xPL entre autres).

supposant un processus de saisie du genre: saisie->revue->commit est-ce qu'un tel processus ne bénéficierait pas du multithreading si les opérations s'avèrent être nombreuses? de plus, il est envisageable que ce soft soit concurrent multi-user, avec un remote db sur un serveur et plusieurs opérateurs. un thread data dédié aux transactions, vérifications, actualisations des changements ne serait-il pas préférable dès le départ?

encore un avec un port audio non-standard

je viens de parler avec notre comptable

si j'ai bien compri la discussion de l'autre discussion, il est recommandé de séparer les couches du soft en threads indépendantes. je ne suis pas assez qualifié pour juger de la pertinence de cet argument.

dire que Qt s'intègre bien dans les bureau Gnome, c'est un peu inexact, mais bon. je pense que ce point est débatable. j'ai jamais travaillé avec PyQt (je suis pas un fan de KDE, déjà donc, je suis peut-être prédisposé). je n'aime pas le look des widgets KDE; mais ça n'a rien à voir avec le sujet. si on arrive à avoir un consensus sur le fait que Qt permettra peut-être un meilleure niveau d'acceptation du soft dans des environnements hétéroclites, je suis prêt à apprendre. il faudrait sans doute comparer deux mockups gtk qt d'une même interface et soumettre à l'appréciation des autres. sujet ouvert.

de plus? je dirais plutot: de différent une autre façon de concevoir un système opérationel, des logiciels, basé sur la communauté plutot que sur le retour sur investissement; bref une autre philosophie. Rien qui rende la vie du gamer plus facile en tous cas.

un langage GPL (ce qui exclut JAVA, .NET, et autres du même genre) et peu-être même qu'on va faire les choses bien et essayer de coder un soft qui puisse utiliser les multicore si existant. challenge pour challenge, autant essayer de sortir un soft de vraiment bonne qualité (voir thread sur le parallelisme) si vous ne voulez pas y participer directement, au moins, n'hésitez pas à donner des conseils (dans tous les domaines). par exemple, si quelqu'un dispose de documentation sur les lois qui régissent la gestion de stock par informatique, je serais ravi de les avoir.

le ping sur tripoli donne toujours de très mauvais résultats. essaie Elda ou paris. c'est plus réaliste. Fawri 2M pro.

lol, avant de commencer à parler de code, j'aimerai d'abord que ceux qui sont interressé rejoigne la discussion pour parler du cahier de charge (virtuel) de ce soft, si possible.

J'ai choisi python/gtk parce que j'ai déjà travaillé avec, et que je ne serais pas trop perdu, et parce que je sais que ça me permet de créer un outil multiplateforme, mais je suis ouvert à toute proposition, je souhaiterais que ce projet devient un projet communautaire, donc si quelqu'un pense, avec justification, qu'un autre language serait plus approprié, je suis prêt à écouter, et meme à l'apprendre si nécéssaire. par contre, j'ai deux critères incompressibles: 1- language opensource 2- soft multi-platforme si je reste seul sur le projet, il est évident qu'il sera en python de toute façon.

ce que le soft devrait pouvoir faire: (standard) ajout de catégorie d'item gestion des fournisseurs ajout d'item listing d'item (par catégorie) recherche sur catégorie check-in/check-out affectations (possibilité lien ldap) alertes de rupture de stock exportation d'inventaire conforme aux normes en vigueur (pdf/ods/xls?) exportation d'inventaire séléctif (pdf/ods/xls?) statistiques (graphes) de mouvement sur stock (optionel) module code barre qu'est-ce que j'ai oublié?

il faut croire que oui. la question est : pourquoi?

je trouve que c'est totalement dans le contexte. au train ou les installations de caméras vont dans le monde, ce n'est pas si ridicule. cell+gps = "depuis quand travailles-tu au sheraton! rentres tout de suite!!!"