[Thread officiel] GnuStock

Ce thread est dédié au projet OSS GnuStock lancé sur ce forum

Le projet:

Le but de ce projet est de développer en communauté et sous licence GPL une application multi-plateforme (Windows, Mac OSX, Linux) de niveau professionnel dédiée à la gestion des stock.

Développement:

-Le langage de codage:

Le choix s'est porté sur Python.

-La librairie graphique:

Elle est encore indéfinie. Etant donné que nous partons sur python, deux choix logiques se proposent à nous: GTK+ (Gnome)et Qt (Nokia). Les mérites de chaque librairie sont nombreux, et elles se valent à plusieurs niveaux. Une décision finale sera prise incessamment.

- la base de donnée:

Le logiciel GnuStock se veut modulaire. Il doit donc être en mesure de gérer plusieurs scénarios (poste unique, user unique, multiposte, multiuser), et de bien s'intégrer dans une architecture DBMS existante. SQL s'impose donc comme le dénominateur commun. Dans cette optique, plusieurs possibilités s'offrent à nous: MySQL, PostgreSQL, MS SQL, Oracle, pour ne citer que celles là. Prendre en compte les spécificités de chaque type de DBMS serait bien trop onéreux en temps et en ressources. La solution est d'utiliser une alternative agnostique, qui permettrait aux codeurs de se libérer de syntaxes spécifiques. Le choix actuel est posé sur l'ORM Sqlalchemy.

Etant un projet spontané (non-commissionné), il n'est prévu pour l'instant aucun ETA.

Nous comptons sur la participation de la communauté de ForumDZ, sa créativité, son professionnalisme, pour affiner ce produit dans le concept et dans l'exécution. les participations sont les bienvenues

A: Sites

1 - définition hierarchie entreprise (siège/annexe)

2 - fiche site (adresse, niveau d'autonomie, etc...)

3 - identification ID site (pour installations annexes seulement - wizard?)

B: Approvisionnements

1 - sources d'approvisionement (fournisseurs)

1a - fiche fournisseur (adresse, etc...)

1b - historique des proformas (voir l'évolution des prix d'un fournisseur)

1c - notations fournisseurs (points forts/points faibles)

1d - suivi/résolution contentieux (c'est l'expérience qui parle)

2 - historiques de transaction par source

3 - catégories d'item

3a - stock commercial (marchandises)

3b - stock de transformation (matière première/pièce détachée)

3c - stock opérationel (moyens généraux)

4 - fiche item

4a - Numero ID applicable selon la loi

4b - unité de mesure

4c - attributs (etiquettable, consommable, durée de vie, etc...)

4d - seuil de réapprovisionement

5 - comparatifs fournisseurs sur item

6 - demandes d'approvisionement

6a - formulaire de requête

6b - calendrier

7 - file d'attente / niveau de priorité de demande (FIFO/LIFO)

8 - validation de demande par role superviseur (**)

C: Entrées

1 - bon de reception suivant demande (A4)

2 - codification et label(étiquette/code barre) si applicable

3 - service fait si applicable

4 - statistiques filtrables sur les entrées (période/source/etc...)

5 - calendrier d'entrées programmées.

D: Sorties

1 - bon de sortie

2 - disptaching

2a - vers département

2b - vers dépot annexe

[...]

E: analyses stock

1 - listing

2 - alertes

2a - rupture

2b - maintenance / réforme

2c - revue nouveaux items/fournisseurs

3 - statistiques/prévisions de consommation

3a - etat des consommations

3b - evolution de stocks (par catégorie)

3c - évolution des prix d'achat par item sur une période donnée.

4 - inventaires

F: Tableau de bord

[...]

G: Configurations

1 - selection mode d'installation

1a - monoposte

1b - multiposte

1b-1 - selection Base de donnée data (wizard)

1b-2 - module d'authentification (wizard)

1b-2a - sql => module de création/gestion d'utilisateurs

1b-2b - ldap => serveur ldap

1b-3 - module ACL/role

2 - plugins

2a - mailer

[...]

(* multi-site)

(** ACL)

Page launchpad de la team dédiée à ce projet, (et aux suivants, le cas échéant)

Pour rejoindre la team, il vous faut un compte launchpad (facile à ouvrir).

réservé aux captures d'écran

bon, pour l'instant ça ressemble plus à un ensemble de fonctionnalités désorganisées non ? (c'est juste un avis, ne le prenez pas mal)

Ne serait il pas plus intéressant de formuler tout ça sous forme de phrases, avec des enchainements d'évènements.

Que pensez vous de partir sur cette description : Gestion stock

ébauche

Edit: Pourquoi avez vous mis plusieurs discussions sur des forums/sous-forums différents, il est un peu difficile de suivre les nouveaux messages comme ça. Pourquoi ne pas tout mettre dans le forum parent: developpement Dz

bon, pour l'instant ça ressemble plus à un ensemble de fonctionnalités désorganisées non ? (c'est juste un avis, ne le prenez pas mal)

je ne dirais pas désorganiées, vu qu'elles sont groupées par sections et relevance thématiques, à mon avis, mais bon; je suis qu'un pauvre sysadmin...

Ne serait il pas plus intéressant de formuler tout ça sous forme de phrases, avec des enchainements d'évènements.

à partir de ce groupement, je pense que les phrases sont faciles à construire. c'est une technique de brouillon de rédaction que j'utilise souvent. je n'ai juste pas le temps de rédiger maintenant; mais j'espère que le flow est apparent malgré tout.

Que pensez vous de partir sur cette description : Gestion stock

je l'ai lue. très complet. très utile, si tout ce la est valable en algérie.

ébauche

.docx, no can do: linux. réessayez avec .doc, peut-être?

.docx, no can do: linux. réessayez avec .doc, peut-être?

ébauche

Bon, je rappelle que c'est pratiquement vide (le cahier de charges est un copier/coller du PDF). une modélisation du contexte dépendra du cahier de charges. le diagramme des cas d'utilisation et de classes viendra après (même si normalement il y a d'autres diagrammes entre les deux pour clarifier le fonctionnement du système).

Une fois le projet bien définis (fixer les fonctionnalités essentielles à implémenter), le codage peut commencer après l'établissement d'un diagramme de classes. Vous pouvez choisir la méthode XP pour suivre un processus de développement. C'est toujours mon avis, à d'autres de contester ça et de proposer autre chose.

ébauche

 

Bon, je rappelle que c'est pratiquement vide (le cahier de charges est un copier/coller du PDF). une modélisation du contexte dépendra du cahier de charges. le diagramme des cas d'utilisation et de classes viendra après (même si normalement il y a d'autres diagrammes entre les deux pour clarifier le fonctionnement du système).

Une fois le projet bien définis (fixer les fonctionnalités essentielles à implémenter), le codage peut commencer après l'établissement d'un diagramme de classes. Vous pouvez choisir la méthode XP pour suivre un processus de développement. C'est toujours mon avis, à d'autres de contester ça et de proposer autre chose.

c'est un bon début, vu que le pdf synthétise bien ce qui doit se passer dans ce soft.

les fonctionalités essentielles sont un sujet à débattre ici avec les autres personnes interessées.

pour les classes, je crois que d'entrée de jeux on peut identifier les classes de base:

Classe Site

Classe User

Classe Fournisseur

Classe Catégorie

Classe Item

Classe Receveur (superclasse)

Classe Requête (superclasse)

Classe Rapport (superclasse)

Pour les classes, je préfère attendre un petit peu.

voilà un diagramme de cas d'utilisation simple : ébauche 2

Reste à clarifier les acteurs qui interagissent avec le système (Employé et Responsable sont à titre indicatif)

hierarchie possible (en sachant que c'est un système modulaire)

Responsable structure

responsable dépot

agent de saisie

Salut,

ébauche 3

Les responsabilités des différents acteurs que vous avez cité restent à définir.

J'ai ajouté une petite description non complète des différents cas d'utilisation. Je rappelle que ces uses cases seront amenés à être complétés au fur et à mesure de l'avancement du projet. Tout le monde peut y participer.

Je voudrais aussi revenir sur le choix de la bibliothèque graphique. Je crois que vous avez opté pour GTK (que je ne connais pas), mais il faudrait voir les fonctionnalités qu'elle offre pour implémenter la couche graphique.

Pour avoir programmé des interfaces graphiques en Java/Swing, je peux dire que développer des logiciels de gestion avec ce langage est très pénible. donc le choix d'un framework adéquat est très important.

Faut voir aussi ce que le langage phyton offre comme possibilités.

Au reste des participatns: veuillez lire et commenter le travail actuellement en cours par bassim pour pouvoir en discture et mettre en place le programme de développement.

Bonjour à tous.

Pendant plusieurs mois, vous avez du constater mon absence du milieu du social networking, et je m'en excuse.

Je compte rendre une vitesse de croisière à ce projet à partir du mois prochain.

Stay tuned.