Discussion :

[b_reda31]

Bonjour,
Dans mon projet de gestion commercial et stock multi-depot , je pense à regrouper l'ensemble des documents que je manipule (devis, facture client , facture fournisseur, avoir client avoir fournisseur, BL client, BR fournisseur,...etc) en une seule table : "Piece".
L'idée vient du fait que (presque) toutes ces pieces ont les mêmes informations (globalement).

Je vois donc les chose de cette manière :
Table PIECE (IdPiece, IdTypePiece, date, ...autres rubriques)

TABLE DETAILS_PIECE(IdDetailP, IdPiece,IdProduit, QT, ...autres rubriques)

Table TYPE_PIECE(idTypePiece, désignation, Abreviation,Stock,Sens...autres rubriques)
La rubrique "Stock" me permettrait de définir si le type de pièce agit sur le stock (Bon réception, Bon livraison...etc) ou non(devis, facture, avoir)
La rubrique "Sens" me permettrai de définir le sens du mouvement par rapport au dépôt (entree ou sortie).

Que pensez vous de cette analyse ?

Merci par avance
Réda

[CinePhil]

Bonjour,

Dommage, ça partait bien !

Ce que vous pouvez faire est un mécanisme d'héritage de données.

Règles de gestion :
R1 : Un devis est un document et un document peut être un devis.
R2 : Une facture est un document et un document peut être une facture.
R3 : Une facture client est une facture et une facture peut être une facture client.
R4 : Une facture fournisseur est une facture et une facture peut être une facture fournisseur.
...

MCD :
Devis -(1,1)----être----0,1- Document
Facture -(1,1) ----être----0,1----|
|-0,1----être----(1,1)- Facture_client
|-0,1----être----(1,1)- Facture_fournisseur

Tables :
te_document_doc (doc_id, doc_date, [propriétés communes à tous les documents])
th_devis_dev (dev_id_document, [propriétés spécifiques aux devis])
th_facture_fac (fac_id_document, [propriétés communes à toutes les factures])
th_facture_client_fcc (fcc_id_facture, fcc_id_client, [propriétés spécifiques aux factures client])
th_facture_fournisseur_fcf (fcf_id_facture, fcf_id_fournisseur, [propriétés spécifiques aux factures fournisseurs])

[b_reda31]

Bonjour Cinephil,
Merci de vos explications et conseils.

Je n'ai pas l'habitude d'utiliser la notion d'Orienté Objet dans mes conceptions, mais je pense avoir saisi le principe que vous évoquez.
l'ensemble des table créees seront des table héritées à partir d'une table "mère" qui regroupe l'ensemble de propriétés communes entre tous les documents. et chacune des tables héritées sera "surchargée" (je ne sais pas s'il s'agit du bon terme) par des propriétés qui lui sont propre. ça a l'air super propre, l'avantage c'est que cela va nous éviter d'avoir trop de valeur nulle dans certains type de documents ...

Je vais voir s'il y a possibilité de mettre en place votre solution avec mon environnement de dev Windev

Merci encore

Réda

[b_reda31]

Bonjour,
Toujours dans ma phase de conception, je suis confronté à un nouveau dilemme.
Ceci concerne essentiellement les règlements client.

Prenons un scénario.

à une date D1, On Génère un Bon de Commande Client BC1 (1000$)
Le client verse un montant de 400$ lors de sa commande

à une date D2, on livre le client en générant le BL1 (depuis le BC1) et nous verse un montant de 500$

Le client nous doit donc 100$.Mais, On doit être en mesure de calculer le reste à payer au niveau de chaque pièce.
Dans ce cas ci, les pièces sont liées. Peut on dire que le reste à payer est de 100$ pour les deux pièces BL et BC?

Si c'est le cas, je pense donc ajouter une propriété "IdGroupePiece" dans l'entité pièce.
De cette manière deux pièces "liées" auront le même groupes et chaque versement est lié à un groupe de pièce et non à une pièce.
et ainsi le reste à payer sera identique au niveau de toutes les pièces du même groupe.
Pensez-vous que ça soit une bonne démarche ou avez vous des suggestions ?

[CinePhil]

Une livraison ne se fait pas dans le vide ; elle correspond à une à plusieurs commandes.

Exemple...

Le client Dupont commande 100 ramettes de papier A4, 5 boîtes de 50 stylos Bic Cristal, 300 paquets de Post-it 15x10 jaunes. Montant total de la commande : 500 euros (aucune idée des prix, c'est juste pour l'exemple).

Le stock est insuffisant et on ne livre que 75 ramettes, tous les stylos et tous les Post-it. La livraison 1 donne lieu à une facture de 410 euros.

Une fois le stock réapprovisionné, on effectue une seconde livraison des 25 ramettes de papier manquantes. La livraison 2 est accompagnée d'une facture de 90 euros.

Dans ce scénario, il y a :
- 1 commande C1 composée de plusieurs lignes de commandes ;
- 1 livraison L1 concernant toutes les lignes de la commande C1 mais une ligne est livrée partiellement ;
- 1 facture F1 correspondant à la livraison L1 ;
- 1 livraison L2 concernant le solde d'une ligne de la commande C1 ;
- 1 facture F2 correspondant à la livraison L2.

Il pourrait aussi y avoir :
- une livraison qui concerne les lignes de plusieurs commandes ;
- une facture mensuelle pour toutes les livraisons effectuées dans le mois précédent ;
- un paiement d'une facture mais en plusieurs fois ;
- un paiement regroupant plusieurs factures...

Ce qu'il faut regarder, c'est à quoi se rapporte chaque élément ; écrire les règles de gestion des données correspondantes et réaliser le MCD.
La ligne de commande est identifiée relativement à la commande.
La ligne de livraison est identifiée relativement à la ligne de commande.
La ligne de facture est identifiée relativement à la ligne de livraison si le détail de la facture est effectué ligne à ligne ou bien à la commande si chaque commande est facturée séparément.
Le paiement est identifié relativement à la facture.

Faites les choses dans l'ordre ! Écrivez vos règles de gestion et revenez nous voir avec ces règles et le début du MCD que vous en aurez tiré.

[b_reda31]

Bonsoir,
Merci du temps consacré CinePhil,
Je suis conscient d'avoir mal posé le problème et qu'un ensemble de règles de gestion s'impose.
C'est justement ça le problème, l'établissement d'un ensemble de règles, qui soit plus ou moins "standard" et qui s'adapte à des PME pour gérer leur commerce tout en restant dans la réglementation...
Bien entendu, la réglementation peut changer d'un état à un autre mais les "grandes lignes" restent les même à mon avis.

J'essaie ici de synthétiser ma compréhension des choses, peut être que je suis dans l'erreur, c'est pour cela que j'aurai besoin de conseil.


Le SI doit regrouper un ensemble de types pièces (documents), certains d'entre eux agissent sur le stock (positivement ou négativement), d'autres non.
Les Type de Pièces que j'ai pu identifier pour le moment sont les suivants, je les ai catégorisé en 2 familles :

Pièce Fournisseur :
Commande Fournisseur : Pas d'effet sur le Stock
Bon de Réception Fournisseur : Incrémente le Stock
Facture Achat Fournisseur : Pas d'effet sur le Stock
Bon de Retour Fournisseur : Décrémente le stock
Avoir Sur Facture Fournisseur: Pas d'effet sur le Stock

Pièce Client
Facture Proforma (Devis) : Pas d'effet sur le Stock
Commande Client : Pas d'effet sur le Stock
Bon de Livraison Client : Décrémente le stock
Facture : Pas d'effet sur le Stock
Bon de Retour Client : Incrémente le Stock
Avoir sur Facture Client : Pas d'effet sur le Stock



Une Pièce Concerne un Tiers (Qui peut être soit un fournisseur, soit un client), l'idée de regrouper client et fournisseur en "tiers" est un autre problème à débattre dans un autre sujet....

Une pièce se compose d'un ou de plusieurs Produits avec une quantité et un prix unitaire au moment de l'établissement de la pièce.

(J'ignore pour le moment le multidépôt)

Le processus d'une vente peut avoir plusieurs scénarii en voici quelques uns sans être exhaustif car les possibilités son énormes)
S1
"Facture proforma" qui passe en "bon de commande client" puis en "Bon de livraison" et enfin en "facture"

S2 : Un Bon de commande qui se divise en plusieurs "Bons de Livraisons" qui se rejoignent à leurs tours en une seule "Facture"

S3 : Plusieurs bon de commande qui se regroupent en un seul "Bon de Livraison" et en une seule "facture"

S4 : Cas d'une vente au comptoir ? là il s'agit bien d'un bon de livraison avec règlement sans bon de commande et sans facture ?


...etc.

On peut remarquer que certaines pièces ici sont "liées" et cette liaison peut être de plusieurs manière différente :
- Les détails des pièces liées sont identiques : Cas S1
- Les détails des pièces liées n'est pas le même, la différence étant calculable pour savoir ce qui reste à livrer (cas S2) ,
tout comme le regroupement est calculable (cas S3 regroupement de BC)

D'un point de vu conception, je n'ai pas traduit dans mon MCD cette liaison que peut exister entre différentes pièces.


L'idée de regrouper toutes les pièce en deux entités (fichier) : pièce et type-pièce, est principalement motivée par le fait de pouvoir factoriser mon code.
Ma vision est d'avoir une seule "procédure" qui permet de créer une pièce quelle que soit son type. en fournissant à cette procédure un certains nombre de paramètre, le type de document entres autres...
J'aurai une seule fenêtre pour l'édition d'une pièces quelque soit son type et non pas une fenêtre/code pour chaque type de pièce.

Cette conception me permet de pouvoir créer de nouveaux types de pièces dans l'avenir et ce, sans devoir retoucher au binaire (ou très peu).
Le paramétrage d'un nouveau type de pièce se fait au niveau du fichier "TypePièce" à travers les rubriques "Stock" et "Sens"
Ces dernières me permettent de définir respectivement si ce type de pièce agit ou non sur le stock et de quelle manière (+ ou -),
le calcul de l'état du stock devient alors possible à travers une seule interrogation SQL.

Ceci dit, dans mon raisonnement je considère que Lorsqu'une pièce est transformée (ex BC en BL), au niveau physique, Un nouvel enregistrement est crée au niveau de Pièce et plusieurs enregistrement sont crées dans détailPiece, les détails sont donc "dupliqués" partiellement ou totalement avec les mêmes quantités ou avec des quantités différentes, à moins que vous voyez les choses autrement ?Voici un exemple qui illustre mon propos : Nous avons ici un BC (BC1) avec deux produit qui s'est transformé en un BL (BL1).
Après traitement nous aurons 2 lignes dans "Pièce" et 4 dans "DétailPièce"





Je m'interresse maintenant à la partie "Règlement" (paiement)
Un règlement concerne une ou plusieurs pièces
Une pièce peut être réglée par 0 ou plusieurs règlements.

de là, nous pouvons déduire la création d'une entitié "Règlement" et d'une association "ReglementPièce" entre "Piece" et "Reglement".
Mais mon souci se trouve au niveau des pièces "liées" :
si par exemple le client passe une commande BC1 d'un total de 100$ et verse lors de sa commande 60$, puis verse les 30$ à la livraison et enfin 10$ à la facture...
Comment associer les règlements et surtout comment suivre le reste à payer ?

Je vous remercie de m'avoir lu.
Bien à vous.
Réda

[CinePhil]

C'est pas mal ; ça progresse.

Je vois des pattes avec 0,1 en cardinalités qui partent de Produit, Piece et TIERS (pourquoi l'avoir écrit en lettres capitales, celui-là ?). Elles vont vers quoi ? Avez-vous mis en oeuvre l'héritage de données ?
Parce qu'avec cette seule partie de diagramme, on ne voit pas les liens entre les commandes, les livraisons, les factures et les paiements.

Il conviendra aussi de corriger les cardinalités de 0,1 en 1,1 dans la plupart des cas : une pièce est d'un seul type, un détail de pièce est associé à une seule pièce et ne concerne qu'un seul produit...

Concernant la fusion des tiers fournisseurs et client : oui, c'est bien comme ça qu'il faut faire. On peut même avoir l'arborescence suivante :
Personne <-- Personne_physique
^------------------Personne_morale
^
|
Tiers <---------Fournisseur
^-----------------Client

L'apparente duplication des détails pièce est normale : une ligne de livraison peut être différente d'une ligne de commande sur le plan de la quantité livrée. Une ligne de facture peut avoir un prix différent de la commande pour cause de remise commerciale (en cas de retard de livraison par exemple).

Je m'interresse maintenant à la partie "Règlement" (paiement)
Un règlement concerne une ou plusieurs pièces
Une pièce peut être réglée par 0 ou plusieurs règlements.

de là, nous pouvons déduire la création d'une entitié "Règlement" et d'une association "ReglementPièce" entre "Piece" et "Reglement".
Mais mon souci se trouve au niveau des pièces "liées" :
si par exemple le client passe une commande BC1 d'un total de 100$ et verse lors de sa commande 60$, puis verse les 30$ à la livraison et enfin 10$ à la facture...
Comment associer les règlements et surtout comment suivre le reste à payer ?

Règle de gestion :
R1 : Un paiement paye une à plusieurs factures et une facture peut être payée par plusieurs règlements.

MCD :
Paiement -1,n----payer----0,n- Facture

Ceci entraînera une table associative porteuse du montant du paiement consacré à la facture. Il sera ainsi facile d'additionner tous les paiements effectués pour payer la facture F125 et comparer cette somme au montant de la facture.

[b_reda31]

Cela sous-entend que l'on associe toujours un paiement à la pièce "facture".
Qu'en est il lorsque le client fait une avance à la commande puis paye le reste à l'établissement de la facture. Dans ce cas ci, nous aurons au niveau du fichier d'association deux lignes de paiement qui concernent la même "vente" mais avec des IdPiece différentes ce qui risque de compliquer le calcul du reste, non ?

[b_reda31]

Je n'ai pas pu mettre en place la notion d'héritage dans mon environnements, pouvons nous traduire ces liaison par le biais d'association ?

[CinePhil]

Qu'en est il lorsque le client fait une avance à la commande puis paye le reste à l'établissement de la facture.

Il faudrait vous renseigner avec les gens du métier comptable mais lorsqu'il y a avance à la commande, n'est-il pas établi par la comptabilité une facture d'avance ?

Dans ce cas ci, nous aurons au niveau du fichier d'association deux lignes de paiement qui concernent la même "vente" mais avec des IdPiece différentes

C'est le cas aussi lorsque qu'une commande est livrée en plusieurs fois et qu'une facture est établie à chaque livraison donc pas de problème.

Je n'ai pas pu mettre en place la notion d'héritage dans mon environnements, pouvons nous traduire ces liaison par le biais d'association ?

Vous parlez de l'environnement de développement Windev ? Ça m'étonne qu'il ne se soit pas encore mis à la Programmation Orientée Objet !
Si vous parlez de l'environnement base de données, je ne connais que PostgreSQL qui ait mis un mécanisme d'héritage de tables mais on peut quand même faire ça avec n'importe quel SGBD. Je vous avais d'ailleurs donné un exemple de tables d'héritage dans un précédent message :

Tables :
te_document_doc (doc_id, doc_date, [propriétés communes à tous les documents])
th_devis_dev (dev_id_document, [propriétés spécifiques aux devis])
th_facture_fac (fac_id_document, [propriétés communes à toutes les factures])
th_facture_client_fcc (fcc_id_facture, fcc_id_client, [propriétés spécifiques aux factures client])
th_facture_fournisseur_fcf (fcf_id_facture, fcf_id_fournisseur, [propriétés spécifiques aux factures fournisseurs])

Pour récupérer par exemple la totalité d'une facture fournisseur, faites une vue qui va rassembler les données du document, de la facture et de la facture fournisseur.

[b_reda31]

Merci Cinephil et désolé de ma réponse tardive.

Comme windev est un AGL, l'environnement de Base de données y est integré et bien qu'il soit possible de travailler en orienté-objet par programmation, cela n'est pas possible dans l'environnement de base de donnée... Je vais me contenter de la table couteau suisse ...

Pour ce qui est du problème du règlement qui suit un ensemble de pièce, je pense ajouter une table de liaison entre pièce qui me permettra de regrouper les règlements qui concernent le même groupe de pièce.

Je reviendrai avec un MCD, dans lequel j'aurai ajouté la partie "Règlement de pièce"

Merci encore

Réda

[sohiermdp]

Windev est capable de communiquer avec de multiples autres bases de données et il n'est pas obligatoire d'utiliser le moteur de base de données HyperFile SQL...