Table Definition - Tuxbee/DepositSale GitHub Wiki
Le projet consiste à créer une application de gestion de dépôt-vente. La base de données doit permettre :
- Gestion des contacts (fournisseurs et clients) : CRM
- Gestion du stock : articles
- Gestion des transactions : journal
- Dépôt : entrée dans le stock
- Retrait : sortie du stock sans génération monétaire
- Vente : sortie du stock avec génération monétaire
- Remboursement : sortie monétaire
Une table de contacts est créée. Il existe 2 types de contacts:
- Client
- Fournisseur
Les informations suivantes sont considérées à propos des contacts :
- Primary Key: ID integer (auto-increment)
- Mandatory : FirstName NVARCHAR(64)
- Mandatory : LastName NVARCHAR(64)
- Mandatory : RegisterDate Date
- OPTIONAL : Adresse :
- StreetAddress : NVARCHAR (256)
- PostCode : NVARCHAR (10)
- City : NVARCHAR (64)
- CountryCode : NCHAR (3)
- OPTIONAL : Mail NVARCHAR (256)
- OPTIONAL : Phone NVARCHAR (64)
- Un premier contact "anonymous" est ajouté et permet de gérer d'éventuels clients non désireux d'être inscrit dans la base de données ou pour anonymiser les précédentes transactions (après la durée légale).
- Aucun journal d'association d'un contact à un service de publicité n'est géré dans cette version. A noter que pour réaliser cette opération, il serait nécessaire de créer un journal incluant des événements d'inscription et de désinscription permettant de retrouver par ID l'autorisation formelle du contact.
Le fournisseur augmente les données de contact comme suit:
- Primary Key : ID integer (Foreign-key Contact)
- Mandatory : IBAN Information NVARCHAR (34)
- Un fournisseur doit obligatoirement être inscrit dans la base de données pour profiter du service "dépôt-vente", cela s'inscrit dans le cadre d'un contrat de vente. Les données relatives à ce contact seront supprimées après le délai imposé par le législateur.
- L'adresse d'un fournisseur est obligatoire.
- Le fournisseur doit obligatoirement fournir un moyen de contact direct (email ou téléphone).
Le client augmente les données de contact comme suit:
- Primary Key : ID integer (Foreign-key Contact)
- Un client du magasin ne doit pas obligatoirement être inscrit dans la base de données pour profiter du service "dépôt-vente". Pour répondre aux aspects légaux, le journal de sortie permet de retracer la vente et éventuellement associer à une transaction bancaire ou liquide à un numéro de journal.
La gestion du stock permet principalement de gérer la liste des articles et le passage de l'article en magasin (assignation d'un prix catalogue).
Les informations suivantes sont considérées à propos des articles :
- Primary Key: ID integer (auto-increment)
- Mandatory : Description NVARCHAR (1024)
- OPTIONAL : CataloguePrice integer
- OPTIONAL : PhotoID (Foreign-key Photo)
- Un article peut être dans différents états (L'état d'un article peut être obtenu par analyse du journal des transactions.) :
- En stock mais pas encore en magasin (pas de prix associé, ni de transaction associée à l'article)
- En magasin (prix associé et aucune transaction associée à l'article)
- Retiré (une transaction de retrait associée à l'article est retrouvée)
- Vendu mais pas remboursé (une transaction de vente est associé à l'article mais pas de remboursement)
- Vendu et remboursé (une transaction de vente et de remboursement sont associées à l'article)
- Un article ne peut avoir été remboursé si il n'a pas été vendu.
- Un article ne peut avoir été retiré s'il a été vendu.
- Un article ne peut avoir été vendu s'il a été retiré
Le vêtement augmente les données de l'article comme suit:
- Primary Key : ID integer (Foreign-key Article)
- OPTIONAL : ColorName NVARCHAR (64)
- OPTIONAL : ColorHexa integer
- OPTIONAL : Size NVARCHAR(16)
Une table des photos permet de retrouver des medias associés aux entités
- Primary Key : ID integer (auto increment)
- Mandatory : MediaName NVARCHAR (64)
- Mandatory : MediaPath NVARCHAR (256)
- OPTIONAL : MediaDescription NVARCHAR (1024)
Une table de journalisation est créée Il existe 4 types d'événement:
- Dépôt : entrée dans le stock
- Retrait : sortie du stock sans génération monétaire
- Vente : sortie du stock avec génération monétaire
- Remboursement : sortie monétaire
Les informations suivantes sont considérées à propos d'un événement :
- Primary Key : ID integer (auto increment)
- Mandatory : EventDate Date
- Les événements sont entrés chronologiquement, il n'est pas possible d'avoir un retrait avant un dépôt associé aux mêmes articles.
Contient les événements d'entrée / sortie d'article pour un fournisseur, l'événement stock-fournisseur augmente les données de l'événement de base comme suit:
- Primary Key : ID integer (Foreign-key Journal)
- Mandatory : IDfournisseur integer (Foreign-key Fournisseur)
- Un reçu pourrait être demandé lors du retrait des articles et associés à l'ID.
Cette table précise les articles fournis lors d'un événement Stock-Fournisseur. Les informations suivantes sont considérées :
- Mandatory : ArticleID integer (Foreign-key Article)
- Mandatory : EventID integer (Foreign-key Journal Stock-Fournisseur)
- La clé est l'ID d'article car un article ne peut être déposé qu'une fois
Cette table précise les articles retirés lors d'un événement Stock-Fournisseur. Les informations suivantes sont considérées :
- Mandatory : ArticleID integer (Foreign-key Article)
- Mandatory : EventID integer (Foreign-key Journal Stock-Fournisseur)
- La clé est l'ID d'article car un article ne peut être retiré qu'une fois
Contient les événements de type 2, l'événement vente augmente les données de l'événement de base comme suit:
- Primary Key : ID integer (Foreign-key Journal)
- Mandatory : IDClient integer (Foreign-key Client)
- Mandatory : TransactionType integer
- 0 : bancaire
- 1 : liquide
- L'ID de vente devrait être utilisé en communication bancaire.
Cette table précise les articles vendus lors d'un événement Vente. Les informations suivantes sont considérées :
- Mandatory : ArticleID integer (Foreign-key Article)
- Mandatory : EventID integer (Foreign-key Vente)
- Mandatory : SellingPrice integer
- La clé est l'ID d'article car un article ne peut être vendu qu'une fois
- Un article ne peut être vendu s'il a déjà été retiré (présent dans Articles Retirés)
Contient les événements de type 3, l'événement Remboursement augmente les données de l'événement de base comme suit:
- Primary Key : ID integer (Foreign-key Journal)
- Mandatory : IDfournisseur (Foreign-key Fournisseur)
- Mandatory : TransactionType integer
- 0 : bancaire
- 1 : liquide
- L'ID de remboursement devrait être utilisé en communication bancaire.
- Un reçu devrait être demandé en cas de remboursement en liquide.
Cette table précise les articles remboursés lors d'un événement Remboursement. Les informations suivantes sont considérées :
- Mandatory : ArticleID integer (Foreign-key Article)
- Mandatory : EventID integer (Foreign-key Remboursement)
- Mandatory : RefundPrice integer
- La clé est l'ID d'article car un article ne peut être remboursé qu'une fois
- Un article ne peut être remboursé qu'après avoir été vendu (présent dans articles vendus)
- Un article ne peut être remboursé qu'une fois (pas déjà présent dans les articles remboursés)
- La marge pour le magasin est définie comme la somme des prix de vente des articles auxquels on retire la valeur du remboursement. (Doit-on considérer cette valeur comme la valeur ajoutée et dès lors en déduire la TVA ?)
Les optimisations suivantes pourraient être réalisées :
- Spécifier dans l'article qu'il ne doit plus être considéré car un processus complet a été réalisé :
- Fournis puis retirés
- Fournis, vendu et remboursé
- Retirer une fois par an de la base de données les tuples correspondant à des processus terminés et ne conserver que les tuples en cours correspondant aux articles fournis, non retirés et non vendus ou non remboursés.
- Suppression des tuples correspondant à des processus complets
- Recréer une base de données à partir de la base de données en cours en ne conservant que les tuples correspondant à des processus incomplets et archiver la précédente.