Discussion :

[charlieda]

Bonjour à toutes et à tous,

Voilà bien longtemps que je n'ai plus mis les mains dans access.

Je demande vos avis et aides concernant ce nouveau projet

Je voudrais gérer l'achat et la vente de matériel informatique d'occasion.

L'idée est donc d'avoir une table avec tout le matériel qui rentre en stock (même si il est vendu)
Cette table me donne les infos du matériel (tant technique que financier)

J'ai des requetes qui me gère ce qui est réellement en stock et ce qui est réservé par des clients (c'est de la vente par correspondance)

Je voudrais ajouter la gestion des factures et là j'ai pas la moindre idée de la procédure.

Merci de me donner votre avis sur ce que j'ai déjà fait.

Merci de m'indiquer comment je pourrais faire pour la gestion des factures.

Merci d'avance pour vos avis et aides.

[pyloupylou]

il y a au moins 2 discussion en relation avec ton sujet: il serait bon que tu les examines d'abord:

[AC-2000] Modélisation d'une Base de données de suivi de facturation
Créée par milkoseck, 09/12/2014 18h14
[AC-2013] Débutant validation MODELISATION d'une entreprise de vente
Créée par olisaeba, 17/12/2014 21h46

[charlieda]

Bonjour,

Merci pour ta réponse.

Effectivement, j'ai vu ces sujets.
En fait, je me demande si ma base est bonne ou pas ?
Devrais je faire plusieurs tables au lieu d'une seule qui regroupe tout ?

Ensuite le problème de facturation mais là j'y suis pas encore

Merci

[pyloupylou]

il faut comprendre le modèle relationnel d'une bdd et dissocier toujours l'aspect stockage de l'aspect restitution
si je dis cela c'est que j'ai l'impression que tu raisonnes excel

un exemple , tu as un ordinateur ( avec type de processeur, écran, mémoire, taille hd ) si tu l'as 40 fois en stock et que son prix bouge de 10ct, tu vas le modifier 40 fois ?
par ailleurs ( si tu fais de l'assemblage et qu'un écran baisse de 20 euros ) ce serait bien que cela soit répercuté sur l'ensemble des configs utilisant cet écran?
lorsque on saisit une information, il faut raisonner transaction et dans une transaction c'est l'aspect accès direct à l'information qui prime.
tout cela pour dire, qu'il faut raisonner plusieurs tables, plutôt qu'une table, et établir des relations.

[charlieda]

Rebonjour,

Merci pour ta réponse.

Oui je dois très certainement être trop excel dans mon esprit

Je comprends très bien ce que tu expliques maismon raisonnement est le suivant (qui tient compte du côté spécifique de mon activité)

Je vends des ordinateurs portables d'occasion (uniquement ce genre de matériel)

Donc pour une question de gestion et de garantie après vente, je suis parti sur l'idée d'identifié le matériel par son numéro de série unique à chaque machine.
Donc chaque machine étant (pour ma part, et c'est peut être sur ce point que je me trompe) unique, même si j'en ai 40 de la même configuration, je la ferai apparaître 40 fois dans mon stock de manière unique.

En fait, je fais cela pour deux raisons :

- savoir à qui j'ai vendu quoi (toujours en partant de ce principe de matériel unique)
- associer la clé windows à la machine (vu que j'ai les licences windows sur chaque machine)

En quelques mots, voilà mon process de travail quand des portables rentrent en stock.
Je prends les infos suivantes :
- n° de série du portable
- n° de clé windows
- ensuite je démarre la machine
- Marque, modèle, config (processeur, ram, hdd,........)
- Installation (windows, pilotes, activation windows)
- Test de la machine (défaut écran, autonomie batterie, ......)


Donc tu me conseilles de faire plusieurs tables, ça j'ai bien compris mais comment faire, sur quelle base et quel principe ?

Une tbl avec le n° de série
une tbl avec la marque modèle config du portable, clé windows
une tbl avec les remarques (défaut, autonomie)
une tbl avec l'aspect financier (prix d'achat, prix de vente, frais de réparation, d'envoi, .......)

Suis je sur la bonne voie ? (quoiqu'en me relisant, je me rends compte que je réfléchis toujours sur la base unique de l'objet ?)

Merci pour ton aide.

[pyloupylou]

je comprends le souci, mais reste persuadé qu'il y a des informations qui sont spécifiques à ta config ( exmple les numéros de séries )
mais des informations plus de type référentielles
exemple
une config ( numero de config avec les numéros de séries du poste et windows, et le type suivant la granularité que tu souhaites, soit portable soit plus fin, donc des informations intraséquement liées à ta config ) et ensuite les informations plus 'générale', ref portable, mémoire etc

ensuite une table portable
ref portable, et les caractéristiques du portable

regarde le dernier post que je t'ai indiqué, à la fin il y a un exemple de gestion d'objet avec de multiple caractéristiques, cela va peut être te donner des idées

[charlieda]

Je te remercie pour ta réponse.

Je vais regarder tout ça plus en profondeur avec un autre oeil

Je reviens sur le sujet dans la semaine.

Déplacement de quelques jours en vue (un ordinateur et une connexion ne sont jamais loin)

Merci encore.

[musafiri]

j'y utiliser Excel pour imprimer les extraits de compte clients, chaque client à une feuille. je suis débitant en Access, formaliser ces idées en Access, à chaque fois quand le client arrive faire le dépôt(versement) dans son compte, qu'il soit créditeur et s'il vent retirer qu'il soit débiteur. Que tous les client et leurs sois compte soient seulement dans une BDD

[pyloupylou]

bonjour et bonne année

@musafiri, tu devrais ouvrir une discussion, ça sera plus simple à suivre

[charlieda]

bonjour et bonne année

@musafiri, tu devrais ouvrir une discussion, ça sera plus simple à suivre

Bonjour et bonne année.

Je rebondis sur le sujet (que j'ai lancé )

Que penses tu de l'idée de créer une table avec les configurations possibles et d'y lier une autre table avec les infos spécifiques (n° de série et n° de licence windows)

Ensuite j'ai un souci dans le principe vu qu'une même config peut avoir deux prix différents

Merci

[pyloupylou]

bah oui, quels sont les critères de détermination du prix ?

[charlieda]

bah oui, quels sont les critères de détermination du prix ?

Merci pour ta réponse en ce jour de mal de tête

Le prix est déterminé en fonction de mon prix d'achat mais plus précisemment j'achète par lot donc en fait le prix est en fonction de l'état physique de la machine plus que celui de la configuration.

Merci

[pyloupylou]

donc ton prix est réellement lié à ta machine, et pas à ta config

[charlieda]

donc ton prix est réellement lié à ta machine, et pas à ta config

Oui disons que c'est le principe. Dans la grande majorité, les prix sont similaires mais bon il faut que je prévois quand meme d'avoir des prix différents.

Merci

[pyloupylou]

donc rien ne t'empeche de prévoir un prix moyen par config, mais que ce prix soit également au niveau de ta machine, et qu'il soit renseigné par défaut par ton prix de config mais reste modifiable

[charlieda]

Je te remercie pour ces infos.

Je vais essayer de modéliser tout ça et je me permets de mettre le fichier ici pour avis et conseils

[charlieda]

Bonjour,

Quand meme un truc qui m'embete (enfin si il y en avait qu'un ) je lie mon matériel avec un champs commun (n° de série) enfin j'imagine...

Mais es ce que je vais devoir à chaque fois indiquer le n° de série dans les autres tables ? faut il faire une zone liste ?

L'idée sera de faire un formulaire avec des sous formulaire tant pour l'encodage que pour la consultation de données.

J'ai donc refait. Les relations sont jointure type 1. Suis completement perdu là. J'ai beau relire les possiblités sais pas quoi mettre

La table client, je ne l'ai pas lié à la clé car il est possible qu'un client achète plusieurs machines donc je ne sais pas si je dois lier ou pas.



J'ai ajouté des sous feuilles à la table clé et du coup, ça a ajouté des relations que j'avais déjà créée.
Bon le principe a l'air de fonctionner mais je ne sais toujours pas si je suis dans le bon....

Merci

PS ; Je n'ai pas mis de champs quantité car oui c'est le principe d'un stock mais je ne sais pas comment gérer l'augmentation de quantité quand j'introduis une machine dans le stock

Merci

[pyloupylou]

je regarde ton modèle, y a des trucs qui me titillent

ton process ( oh le consultant qui ressurgit ...) semble être le suivant
acquisition --> tests ---> stockage ---> vente

ce que tu manipules c'est des portables
un portable c'est un modèle qui correspond à une configuration type ( marque, modèle )
--> qui va avoir n caractéristiques à décrire ( ecran, memoire,.... )
=> ici je partirai sur un principe de méta-modèle (voir le post que je t'avais indiqué) , car avec le nombre de caractéristiques que tu souhaites référencer, je te vois mal modifier la structure de tes tables à chaque fois que tu auras une nouvelle caractéristique à gérer ce qui donnerait:
- un table config_type ( #numero de sequence, marque, modèle )
- une table des caractéristiques ( #numero caractéristique, libelle de la caractéristique )
et la table qui va te permettre de renseigner ces dernières, que je nommerai descro_config avec ( # numero de séquence, #numero caracteristique, contenu ) ce dernier champ va te permettre d'indiquer la valeur stockée pour l'association config_type/caracteristique

ensuite tu vas gérer tes achats et tu vas rensseigner pour chaque portable acheté ( #id_portable (n° sequence), numéro de série, #numero de séquence pour la config , et les autres informations instraséquement liées à ton achat dans la même table : date achat, référence du tiers (on verra ça plus tard ), n° licence windows ....

une fois le portable entre tes mains tu fais des tests dessus
je m'appuierai de nouveau sur la table des caractéristiques et créerai une table etat_portable_detaillé ( similaire à descro config)
reprenant (#id portable, #numero caractéristique, et un champ description pour indiquer le résultat constaté pour le composant vérifié )

voilà des premières pistes ....

[charlieda]

Bonjour pyloupylou,

Je te remercie pour ton message. Alors là je comprends plus grand chose même si le principe me paraît clair (oui je sais, suis bizarre)

D'accord sur le process, c'est très bien vu car il arrive que je doive "mettre de côté" certains portables en vue de réparation, donc l'idée, acquisition test est très bien.


Qu'entend tu par #numero de sequence ? #numero caractéristique ? C'est la numérotation automatique ?

libelle de la caractéristique : cela ne fait il pas doublon avec écran, mémoire, ....... ?

Concernant descro_config (ca veut dire quoi d'ailleurs ) je comprends absolument rien à "contenu ) ce dernier champ va te permettre d'indiquer la valeur stockée pour l'association config_type/caracteristique"

Merci pour ton aide à quelqu'un qui comprend vite quand on lui explique longtemps

[pyloupylou]

au début ça parait compliqué,

en fait j'ai utilisé comme notation # pour indiquer les clefs
oui cela peut être des numéros auto

encore une fois regarde le post http://www.developpez.net/forums/d14...reprise-vente/
( là c'est vrai j'indique le lien exact , regarde à la fin de la discussion il y a un modèle décrit et une base exemple )

en fait tu as une table qui va te lister les caractéristiques gérées par ton système
exemple
1 - écran
2 - mémoire
3 - processeur
4 - disque
5 - etc...

ensuite tu as la table qui te décrit tes configs
1 - DELL - Vostro - etc
2 - ASUS - X70S64fdhgsdfhshf - etc

derrière tu décris ta config avec ( identifiant config, identifiant caractéristique, et le fameux contenu )
donc pour la config 1(le dell)
pour la caractéristique 1(ecran), tu auras 17,3 pouces
pour la 2 (mémoire ) 4Go
pour la 3 (proc) intel Core I5
pour la 4 (disque) 500Go

l'intérêt de ce principe c'est que tu peux gérer autant de caractéristiques que tu veux, si tu préféres tu ne les as plus en colonne de ta table, mais en tant qu'enregistrements

est ce que mon explication est un peu plus claire ?
dans l'exemple fourni considère que la table objet est ta table config
la table description_objet est ce que j'appelle descro_config
et la table caractéristique , bah c'est les caractéristiques