Discussion :

[lucmohamed]

Bonjour,

Voila je voudrais commencer le développement d'un programme simple de gestion de bon de commande dans l'entreprise.
Actuellement ça se fait manuellement sur papier.

Chaque employé peut soumettre un bon de commande qui doit être au préalable validé par la direction.
La direction aura le droit de valider ou de rejeter le bon de commande.

Il y aura surement de l'authentification.

Dans l'espace de la direction, ils verront tous les bon de commande qui sont en attente de validation et ceux déjà validé et ceux rejetés.

Pour l'espace des employés, chaque employé aura dans son espaces l’état du bon de commande qu'il a soumis.


J'ai commencé à mettre en place le modèle conceptuel de donnée déjà que vous pouvez voir en pièce jointe.






Je voudrais de votre part vos idées dessus et je me demande si je pourrais essayer avec un framework comme zend ou je me lance directement dans le développement pur.


A vous.

[Spartacusply]

C'est un bon début déjà. J'apporterais juste quelques modifications :

- pour le bon de commande, il vaudrait mieux regrouper "soumis, valide, rejete" sous un unique attribut nommé "etat" dont la valeur indiquerait l'état du bon de commande (0 = soumis, 1= validé, 2 = rejeté par exemple)
- le prix unitaire doit également figurer dans la table article. Après tu peux le dupliquer (ou non) au niveau de la relation avec bon de commande. Ca dépendra de si la validation met 15 jours à se faire et que le prix de l'article change entre temps, comment ça se passe dans ce cas là ? C'est à réfléchir.
- tu n'as pas à orienter tes relations, ce n'est pas pertinent dans ton cas.
- concernant les noms des attributs et des tables, utilise uniquement des caractères alphanumériques en minuscules plus éventuellement le "_". Pas d'espace, pas d'accent ni de majuscule, ni aucun autre caractère, ça d'évitera bien des soucis par la suite.

Pour la validation, ce système porte un nom, ça s'appelle un workflow.

Continue ton diagramme dans cette voie là pour le modéliser, ce n'est pas très compliqué.

Je voudrais de votre part vos idées dessus et je me demande si je pourrais essayer avec un framework comme zend ou je me lance directement dans le développement pur.

Ca dépends de toi, de ton niveau en Php. Si tu n'as jamais développer aucun "vrai" projet php, le développer en dur (en adoptant tout de même une architecture MVC) pour bien comprendre tous les mécanismes de Php peut-être une bonne idée. Autrement, utiliser un framework peut-être une bonne idée, c'est l'occasion et ca te sera formateur. Par contre, je te déconseillerais d'utiliser un gros framework pour commencer (comme Zend ou Symfony), mais un framework plus léger qui te conviendrait mieux à toi et à ton projet, tel que CakePhP, Laravel, ou CodeIgniter par exemple.

[lucmohamed]

Merci spartacusply pour votre intervention.

C'est une bonne idée le fait de regrouper "soumis, validé et rejeté" sous un seul attribut.

J'ai mis PU dans l’association parce que le prix peut changer d'un moment à l'autre. Qui veut dire qu'on ne peut pas savoir en avance. A voir s'il y a d'autre solutions

Pour le langage de php j'ai deja fais de programme php meme si ca fait 1 ou 2 années que j'ai plus retouché. J'ai un peu peur pour la securité si je le developpe directement. Les frameworks sont bien structurés.

A vous.

[Spartacusply]

J'ai mis PU dans l’association parce que le prix peut changer d'un moment à l'autre. Qui veut dire qu'on ne peut pas savoir en avance. A voir s'il y a d'autre solutions

Indique le uniquement dans l'article alors dans ce cas là si tu veux un tarif en temps réel, mais pas dans la relation, ce qui justement signifierais que tu fixes le prix à un instant t.

Pour le langage de php j'ai deja fais de programme php meme si ca fait 1 ou 2 années que j'ai plus retouché. J'ai un peu peur pour la securité si je le developpe directement. Les frameworks sont bien structurés.

Ok, penche toi vers l'utilisation d'un framework alors.

[lucmohamed]

Indique le uniquement dans l'article alors dans ce cas là si tu veux un tarif en temps réel, mais pas dans la relation, ce qui justement signifierais que tu fixes le prix à un instant t.

si un article dans une commande etait 30 euro et que ce meme article dans une autre commande est de 50euro. comment on va faire ce cas là??

[Spartacusply]

Une fois que le bon de commande est validé et payé tu veux dire ? Dans ce cas là, ok tu peux indiquer le prix définitif (qui a été payé ou qui va être payé) au niveau de la relation. Tant que celui-ci peut varier, prends le prix dans la table article.

[lucmohamed]

Ok pour le prix unitaire.

Pour la validation, ce système porte un nom, ça s'appelle un workflow.

Pourriez vous s'il vous plait me parler un peu plus du workflow.

Mon idée etait avec une requete sql mettre à jour l'attribut "etat".

Quand l'employé soumettra une commande, ce champs devient 1.

Dans l'espace direction, j'afficherais tjrs avec une requete de selection toutes les commandes avec l'attribut etat = 1

S'il valide ce bon, l'attribut etat prend 2 sinon si c'est rejeté 3

Apres dans l'espace employé, ils verront sous differents menus, tous les bon de commande en fonction de leurs etats.


A vous.

[Spartacusply]

C'est bien ça l'idée oui.

[lucmohamed]

le worflow c'est un peu prés ça??

Si c'est meilleur que mon idée je pourrais le prendre.

Autre chose que je voudrais savoir. Merci encore pour votre assistance.

Je voudrais que le numéro de bon de commande soit incrémenté d'une manière à voir l'année en cours + un numéro incrémenté.

Si vous avez une autre idée meilleur, vous êtes le bienvenu.

A vous

[Spartacusply]

Ton projet n'set pas moins bien ni meilleur, ton projet est un workflow, plus précisément un workflow de validation mais par abus de language un workflow étant très souvent un workflow de validation, on dit juste workflow. C'était juste à titre informatif .

Je voudrais que le numéro de bon de commande soit incrémenté d'une manière à voir l'année en cours + un numéro incrémenté.

Comme tu veux, pour le numéro tu peux faire comme tu le souhaites, par contre utilise bien un identifiant uniquement numérique auto-incrémenté comme clef primaire de ta table. A ne pas confondre.

[lucmohamed]

Merci bcp. Je ne sais pas comment vous remercier du temps que vous donnez pour me repondre.

Donc je garde l'attribue num_cde mais j'ajoute un autre attribut alphanumerique code_cde. C'est ce dernier qui contiendra la concatenation de l'année en cours+numero incrementé.

Je pense aussi au lieu de l'année+numero incrementé, je mets date du bon + numero incrementé. LA partie incrémenté sera réinitialisé à chaque fois que la date du bon change.

exemple: 150514-5 ; 160514-1; 170514-1

Qu'est ce que vous pensez de ca??

A vous

[Spartacusply]

C'est une bonne idée. Après c'est vraiment une question organisationnelle, assure toi juste qu'il soit bien unique.

[ascito]

de mon point de vue, mais c'est à prendre au premier degrès tu as un petit problème de relations, dans le sens ou tu penses que déclencher une demande d'achat mène toujours vers une commande.... il manque surement une table intermédiaire te permettant de rendre encore plus souple et robuste ton model !!

[lucmohamed]

Pour ce programme, il va juste gérer le bon de commande en soi. Pas de gestion d'entrée ni de sortie. Juste un bon de commande. Un service ou un employé déclenche le bon de commande que la direction aura le choix d'accepter ou de rejeter. C'est tout. Juste ce qui était au début un peu confus c'est le prix de l'article. C'est à mettre dans la relation entre la table de commande et l'article ou dans l'article. A part ça, tout vas bien. Si vous avez des idées, faites nous partager.

A vous

[Spartacusply]

tu penses que déclencher une demande d'achat mène toujours vers une commande.

SI la direction refuse la demande d'achat, la commande ne sera pas passée évidemment. Je vois pas trop le problème à ce niveau là.