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.