Je cherche à développer une application simple (pas trop de visual basic,
étant donné mon niveau) gérant des stocks de badge de parking. Particularités
:
1) les entrées de stocks sont groupées. Par ex, le 29 déc., je rentre 500
badges neufs d'un coup (n° 1 à 100).
2) Les sorties sont individuelles. Par ex, je sors un badge, le n° 9, pour
kolele;
3) on doit pouvoir entrer à nouveau dans le stock un badge sorti. Ex: le 30,
kolele rend son badge n°9, qui rentre dans le stock et pourra être sorti pour
quelqu'un d'autre.
Je n'ai jamais fais ça ; voici mon idée première : créer 2 tables "ENTREES"
et "SORTIES", avec des règles de validation interdisant d'entrer un badge
déjà entré et de sortir un badge pas entré. Je pensais à des macro sur
propriété "avant mise à jour", avec une condition dans la macro, une boite de
message alertant l'utilisateur et annulant la saisie incohérente.
Reste à écrire la macro et la condition …
Merci à vous pour le coup de pouce ou le commentaire sur le projet, ou des
ex de bases similaires déjà existantes.
Kolele (qui vous souhaite la bonne année)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Le meruvien
bonjour Kolele, c'est une base assez simple dans l'ensemble, que tu peut facilement faire avec l'assistant, mais deja pour commencer, ne fait pas 2 tables, tu en fait qu'une, avec un champ "entrée" et un champ "sortie"! si tu veut de l'aide pour la faire toi meme ou même que je la fasse, contacte - moi: en suppriment RV. Bien sur c'est gratuit! roger
"Kolele" (pitiépasdespam)> a écrit dans le message de news:
Bonjour à tous,
Je cherche à développer une application simple (pas trop de visual basic, étant donné mon niveau) gérant des stocks de badge de parking. Particularités : 1) les entrées de stocks sont groupées. Par ex, le 29 déc., je rentre 500 badges neufs d'un coup (n° 1 à 100). 2) Les sorties sont individuelles. Par ex, je sors un badge, le n° 9, pour kolele; 3) on doit pouvoir entrer à nouveau dans le stock un badge sorti. Ex: le 30, kolele rend son badge n°9, qui rentre dans le stock et pourra être sorti pour quelqu'un d'autre.
Je n'ai jamais fais ça ; voici mon idée première : créer 2 tables "ENTREES" et "SORTIES", avec des règles de validation interdisant d'entrer un badge déjà entré et de sortir un badge pas entré. Je pensais à des macro sur propriété "avant mise à jour", avec une condition dans la macro, une boite de message alertant l'utilisateur et annulant la saisie incohérente.
Reste à écrire la macro et la condition . Merci à vous pour le coup de pouce ou le commentaire sur le projet, ou des ex de bases similaires déjà existantes. Kolele (qui vous souhaite la bonne année)
bonjour Kolele, c'est une base assez simple dans l'ensemble, que tu peut
facilement faire avec l'assistant, mais deja pour commencer, ne fait pas 2
tables, tu en fait qu'une, avec un champ "entrée" et un champ "sortie"!
si tu veut de l'aide pour la faire toi meme ou même que je la fasse,
contacte - moi:
RVvdb.roger@free.fr en suppriment RV. Bien sur c'est gratuit!
roger
"Kolele" <kolele@tiscali.fr.(pitiépasdespam)> a écrit dans le message de
news: 11C66DB2-84B1-4F4A-9977-7E0D531C44F9@microsoft.com...
Bonjour à tous,
Je cherche à développer une application simple (pas trop de visual basic,
étant donné mon niveau) gérant des stocks de badge de parking.
Particularités
:
1) les entrées de stocks sont groupées. Par ex, le 29 déc., je rentre 500
badges neufs d'un coup (n° 1 à 100).
2) Les sorties sont individuelles. Par ex, je sors un badge, le n° 9, pour
kolele;
3) on doit pouvoir entrer à nouveau dans le stock un badge sorti. Ex: le
30,
kolele rend son badge n°9, qui rentre dans le stock et pourra être sorti
pour
quelqu'un d'autre.
Je n'ai jamais fais ça ; voici mon idée première : créer 2 tables
"ENTREES"
et "SORTIES", avec des règles de validation interdisant d'entrer un badge
déjà entré et de sortir un badge pas entré. Je pensais à des macro sur
propriété "avant mise à jour", avec une condition dans la macro, une boite
de
message alertant l'utilisateur et annulant la saisie incohérente.
Reste à écrire la macro et la condition .
Merci à vous pour le coup de pouce ou le commentaire sur le projet, ou des
ex de bases similaires déjà existantes.
Kolele (qui vous souhaite la bonne année)
bonjour Kolele, c'est une base assez simple dans l'ensemble, que tu peut facilement faire avec l'assistant, mais deja pour commencer, ne fait pas 2 tables, tu en fait qu'une, avec un champ "entrée" et un champ "sortie"! si tu veut de l'aide pour la faire toi meme ou même que je la fasse, contacte - moi: en suppriment RV. Bien sur c'est gratuit! roger
"Kolele" (pitiépasdespam)> a écrit dans le message de news:
Bonjour à tous,
Je cherche à développer une application simple (pas trop de visual basic, étant donné mon niveau) gérant des stocks de badge de parking. Particularités : 1) les entrées de stocks sont groupées. Par ex, le 29 déc., je rentre 500 badges neufs d'un coup (n° 1 à 100). 2) Les sorties sont individuelles. Par ex, je sors un badge, le n° 9, pour kolele; 3) on doit pouvoir entrer à nouveau dans le stock un badge sorti. Ex: le 30, kolele rend son badge n°9, qui rentre dans le stock et pourra être sorti pour quelqu'un d'autre.
Je n'ai jamais fais ça ; voici mon idée première : créer 2 tables "ENTREES" et "SORTIES", avec des règles de validation interdisant d'entrer un badge déjà entré et de sortir un badge pas entré. Je pensais à des macro sur propriété "avant mise à jour", avec une condition dans la macro, une boite de message alertant l'utilisateur et annulant la saisie incohérente.
Reste à écrire la macro et la condition . Merci à vous pour le coup de pouce ou le commentaire sur le projet, ou des ex de bases similaires déjà existantes. Kolele (qui vous souhaite la bonne année)
Kolele
Je poursuis la réflexion, en attendant que mon Méruvien bosse pour moi ! Je peux créer une table "Badges" avec un champ "CléBadge", NuméroAuto qui serait clé primaire. Puis une seconde table "Entrées", avec un champ "clé entrée" (numéroAuto et clé primaire), un champ "CléBadge" qui serait le coté-plusieurs de la relation avec la table "Badges". Car mes badges vont "entrer" plusieurs fois dans le stock : la première fois quand ils sont tous neufs, la seconde quand l'utilisateur me le rendra, en attendant de l'attribuer à quelqu'un d'autre. Ensuite une table "Sorties", avec champ "CléSortie" (clé primaire, champ numéroAuto) et un champ "CléBadge" relié à la table badge (relation 1 à plusieurs, avec intégrité référentielle). Car là encore, chaque badge va "sortir" plusieurs fois tout au long de son existence magnétique. Les entrées et sorties de badges à l'unité, je sais gérer. Mais entrer 500 badges d'un coup, je sais pô. Et si je demande à ma collaboratrice de les entrer un à un, je me mange le clavier illico. Merci d'avance pour les tuyaux. Kolele (qui n'a pas fini de vous souhaiter la bonne année).
Je poursuis la réflexion, en attendant que mon Méruvien bosse pour moi !
Je peux créer une table "Badges" avec un champ "CléBadge", NuméroAuto qui
serait clé primaire.
Puis une seconde table "Entrées", avec un champ "clé entrée" (numéroAuto et
clé primaire), un champ "CléBadge" qui serait le coté-plusieurs de la
relation avec la table "Badges". Car mes badges vont "entrer" plusieurs fois
dans le stock : la première fois quand ils sont tous neufs, la seconde quand
l'utilisateur me le rendra, en attendant de l'attribuer à quelqu'un d'autre.
Ensuite une table "Sorties", avec champ "CléSortie" (clé primaire, champ
numéroAuto) et un champ "CléBadge" relié à la table badge (relation 1 à
plusieurs, avec intégrité référentielle). Car là encore, chaque badge va
"sortir" plusieurs fois tout au long de son existence magnétique.
Les entrées et sorties de badges à l'unité, je sais gérer. Mais entrer 500
badges d'un coup, je sais pô. Et si je demande à ma collaboratrice de les
entrer un à un, je me mange le clavier illico.
Merci d'avance pour les tuyaux.
Kolele (qui n'a pas fini de vous souhaiter la bonne année).
Je poursuis la réflexion, en attendant que mon Méruvien bosse pour moi ! Je peux créer une table "Badges" avec un champ "CléBadge", NuméroAuto qui serait clé primaire. Puis une seconde table "Entrées", avec un champ "clé entrée" (numéroAuto et clé primaire), un champ "CléBadge" qui serait le coté-plusieurs de la relation avec la table "Badges". Car mes badges vont "entrer" plusieurs fois dans le stock : la première fois quand ils sont tous neufs, la seconde quand l'utilisateur me le rendra, en attendant de l'attribuer à quelqu'un d'autre. Ensuite une table "Sorties", avec champ "CléSortie" (clé primaire, champ numéroAuto) et un champ "CléBadge" relié à la table badge (relation 1 à plusieurs, avec intégrité référentielle). Car là encore, chaque badge va "sortir" plusieurs fois tout au long de son existence magnétique. Les entrées et sorties de badges à l'unité, je sais gérer. Mais entrer 500 badges d'un coup, je sais pô. Et si je demande à ma collaboratrice de les entrer un à un, je me mange le clavier illico. Merci d'avance pour les tuyaux. Kolele (qui n'a pas fini de vous souhaiter la bonne année).
Kolele
Je pensais à une autre piste : puisque mes entrées de badges se font par série (ex, je rentre d'un coup 500 badges numérotés de 6000 à 6500), je pourrais avoir une table ENTREES avec 2 champs "Valeur plancher" (premier badge entré, ex 6000) et "Valeur plafond" (dernier badge entré, ex 6500). Ensuite, je pourrais, dans la table SORTIES, poser une règle de validation vérifiant que le badge que je veux sortir a bien été précédemment entré (RechDom).
Toutes ces questions existentielles proviennent du fait que, dans mes précédentes appli, je gérais des saisies portant sur un seul enregistrement, et non pas une série entière… J'aurais vraiment besoin d'être cadré. Merci à tous et bises de bonne année.
Je poursuis la réflexion, en attendant que mon Méruvien bosse pour moi ! Je peux créer une table "Badges" avec un champ "CléBadge", NuméroAuto qui serait clé primaire. Puis une seconde table "Entrées", avec un champ "clé entrée" (numéroAuto et clé primaire), un champ "CléBadge" qui serait le coté-plusieurs de la relation avec la table "Badges". Car mes badges vont "entrer" plusieurs fois dans le stock : la première fois quand ils sont tous neufs, la seconde quand l'utilisateur me le rendra, en attendant de l'attribuer à quelqu'un d'autre. Ensuite une table "Sorties", avec champ "CléSortie" (clé primaire, champ numéroAuto) et un champ "CléBadge" relié à la table badge (relation 1 à plusieurs, avec intégrité référentielle). Car là encore, chaque badge va "sortir" plusieurs fois tout au long de son existence magnétique. Les entrées et sorties de badges à l'unité, je sais gérer. Mais entrer 500 badges d'un coup, je sais pô. Et si je demande à ma collaboratrice de les entrer un à un, je me mange le clavier illico. Merci d'avance pour les tuyaux. Kolele (qui n'a pas fini de vous souhaiter la bonne année).
Je pensais à une autre piste : puisque mes entrées de badges se font par
série (ex, je rentre d'un coup 500 badges numérotés de 6000 à 6500), je
pourrais avoir une table ENTREES avec 2 champs "Valeur plancher" (premier
badge entré, ex 6000) et "Valeur plafond" (dernier badge entré, ex 6500).
Ensuite, je pourrais, dans la table SORTIES, poser une règle de validation
vérifiant que le badge que je veux sortir a bien été précédemment entré
(RechDom).
Toutes ces questions existentielles proviennent du fait que, dans mes
précédentes appli, je gérais des saisies portant sur un seul enregistrement,
et non pas une série entière…
J'aurais vraiment besoin d'être cadré.
Merci à tous et bises de bonne année.
Je poursuis la réflexion, en attendant que mon Méruvien bosse pour moi !
Je peux créer une table "Badges" avec un champ "CléBadge", NuméroAuto qui
serait clé primaire.
Puis une seconde table "Entrées", avec un champ "clé entrée" (numéroAuto et
clé primaire), un champ "CléBadge" qui serait le coté-plusieurs de la
relation avec la table "Badges". Car mes badges vont "entrer" plusieurs fois
dans le stock : la première fois quand ils sont tous neufs, la seconde quand
l'utilisateur me le rendra, en attendant de l'attribuer à quelqu'un d'autre.
Ensuite une table "Sorties", avec champ "CléSortie" (clé primaire, champ
numéroAuto) et un champ "CléBadge" relié à la table badge (relation 1 à
plusieurs, avec intégrité référentielle). Car là encore, chaque badge va
"sortir" plusieurs fois tout au long de son existence magnétique.
Les entrées et sorties de badges à l'unité, je sais gérer. Mais entrer 500
badges d'un coup, je sais pô. Et si je demande à ma collaboratrice de les
entrer un à un, je me mange le clavier illico.
Merci d'avance pour les tuyaux.
Kolele (qui n'a pas fini de vous souhaiter la bonne année).
Je pensais à une autre piste : puisque mes entrées de badges se font par série (ex, je rentre d'un coup 500 badges numérotés de 6000 à 6500), je pourrais avoir une table ENTREES avec 2 champs "Valeur plancher" (premier badge entré, ex 6000) et "Valeur plafond" (dernier badge entré, ex 6500). Ensuite, je pourrais, dans la table SORTIES, poser une règle de validation vérifiant que le badge que je veux sortir a bien été précédemment entré (RechDom).
Toutes ces questions existentielles proviennent du fait que, dans mes précédentes appli, je gérais des saisies portant sur un seul enregistrement, et non pas une série entière… J'aurais vraiment besoin d'être cadré. Merci à tous et bises de bonne année.
Je poursuis la réflexion, en attendant que mon Méruvien bosse pour moi ! Je peux créer une table "Badges" avec un champ "CléBadge", NuméroAuto qui serait clé primaire. Puis une seconde table "Entrées", avec un champ "clé entrée" (numéroAuto et clé primaire), un champ "CléBadge" qui serait le coté-plusieurs de la relation avec la table "Badges". Car mes badges vont "entrer" plusieurs fois dans le stock : la première fois quand ils sont tous neufs, la seconde quand l'utilisateur me le rendra, en attendant de l'attribuer à quelqu'un d'autre. Ensuite une table "Sorties", avec champ "CléSortie" (clé primaire, champ numéroAuto) et un champ "CléBadge" relié à la table badge (relation 1 à plusieurs, avec intégrité référentielle). Car là encore, chaque badge va "sortir" plusieurs fois tout au long de son existence magnétique. Les entrées et sorties de badges à l'unité, je sais gérer. Mais entrer 500 badges d'un coup, je sais pô. Et si je demande à ma collaboratrice de les entrer un à un, je me mange le clavier illico. Merci d'avance pour les tuyaux. Kolele (qui n'a pas fini de vous souhaiter la bonne année).
Michel_D
Je pensais à une autre piste : puisque mes entrées de badges se font par série (ex, je rentre d'un coup 500 badges numérotés de 6000 à 6500), je pourrais avoir une table ENTREES avec 2 champs "Valeur plancher" (premier badge entré, ex 6000) et "Valeur plafond" (dernier badge entré, ex 6500). Ensuite, je pourrais, dans la table SORTIES, poser une règle de validation vérifiant que le badge que je veux sortir a bien été précédemment entré (RechDom).
Toutes ces questions existentielles proviennent du fait que, dans mes précédentes appli, je gérais des saisies portant sur un seul enregistrement, et non pas une série entière... J'aurais vraiment besoin d'être cadré. Merci à tous et bises de bonne année.
Plusieurs pistes possibles :
Sans programmation VBA : Action ponctuelle : importation d'un fichier Excel vers ta table.
Sinon avec programmation beaucoup de choses sont possible.
PS:Je crois que Méruvien t'a conseillé une seule table pour gérer tes badges et non pas 2 tables liées à un état de tes badges donc je pense que tu devrais en tenir compte.
Je pensais à une autre piste : puisque mes entrées de badges se font par
série (ex, je rentre d'un coup 500 badges numérotés de 6000 à 6500), je
pourrais avoir une table ENTREES avec 2 champs "Valeur plancher" (premier
badge entré, ex 6000) et "Valeur plafond" (dernier badge entré, ex 6500).
Ensuite, je pourrais, dans la table SORTIES, poser une règle de validation
vérifiant que le badge que je veux sortir a bien été précédemment entré
(RechDom).
Toutes ces questions existentielles proviennent du fait que, dans mes
précédentes appli, je gérais des saisies portant sur un seul enregistrement,
et non pas une série entière...
J'aurais vraiment besoin d'être cadré.
Merci à tous et bises de bonne année.
Plusieurs pistes possibles :
Sans programmation VBA :
Action ponctuelle : importation d'un fichier Excel vers ta table.
Sinon avec programmation beaucoup de choses sont possible.
PS:Je crois que Méruvien t'a conseillé une seule table pour gérer
tes badges et non pas 2 tables liées à un état de tes badges donc
je pense que tu devrais en tenir compte.
Je pensais à une autre piste : puisque mes entrées de badges se font par série (ex, je rentre d'un coup 500 badges numérotés de 6000 à 6500), je pourrais avoir une table ENTREES avec 2 champs "Valeur plancher" (premier badge entré, ex 6000) et "Valeur plafond" (dernier badge entré, ex 6500). Ensuite, je pourrais, dans la table SORTIES, poser une règle de validation vérifiant que le badge que je veux sortir a bien été précédemment entré (RechDom).
Toutes ces questions existentielles proviennent du fait que, dans mes précédentes appli, je gérais des saisies portant sur un seul enregistrement, et non pas une série entière... J'aurais vraiment besoin d'être cadré. Merci à tous et bises de bonne année.
Plusieurs pistes possibles :
Sans programmation VBA : Action ponctuelle : importation d'un fichier Excel vers ta table.
Sinon avec programmation beaucoup de choses sont possible.
PS:Je crois que Méruvien t'a conseillé une seule table pour gérer tes badges et non pas 2 tables liées à un état de tes badges donc je pense que tu devrais en tenir compte.
Kolele
- pistes avec programmation : lesquelles ? - sans programmation : l'importation d'un tableau excel ne permet pas d'entrer et de sortir le meme badge plusieurs fois, et de conserver l'historique. le but de cette appli est d'éditer des cumuls d'entrées, cumuls de sortie par mois et photographie du stock en fin de mois.
Plusieurs pistes possibles :
Sans programmation VBA : Action ponctuelle : importation d'un fichier Excel vers ta table.
Sinon avec programmation beaucoup de choses sont possible.
PS:Je crois que Méruvien t'a conseillé une seule table pour gérer tes badges et non pas 2 tables liées à un état de tes badges donc je pense que tu devrais en tenir compte.
- pistes avec programmation : lesquelles ?
- sans programmation : l'importation d'un tableau excel ne permet pas
d'entrer et de sortir le meme badge plusieurs fois, et de conserver
l'historique. le but de cette appli est d'éditer des cumuls d'entrées, cumuls
de sortie par mois et photographie du stock en fin de mois.
Plusieurs pistes possibles :
Sans programmation VBA :
Action ponctuelle : importation d'un fichier Excel vers ta table.
Sinon avec programmation beaucoup de choses sont possible.
PS:Je crois que Méruvien t'a conseillé une seule table pour gérer
tes badges et non pas 2 tables liées à un état de tes badges donc
je pense que tu devrais en tenir compte.
- pistes avec programmation : lesquelles ? - sans programmation : l'importation d'un tableau excel ne permet pas d'entrer et de sortir le meme badge plusieurs fois, et de conserver l'historique. le but de cette appli est d'éditer des cumuls d'entrées, cumuls de sortie par mois et photographie du stock en fin de mois.
Plusieurs pistes possibles :
Sans programmation VBA : Action ponctuelle : importation d'un fichier Excel vers ta table.
Sinon avec programmation beaucoup de choses sont possible.
PS:Je crois que Méruvien t'a conseillé une seule table pour gérer tes badges et non pas 2 tables liées à un état de tes badges donc je pense que tu devrais en tenir compte.
Michel_D
- pistes avec programmation : lesquelles ? - sans programmation : l'importation d'un tableau excel ne permet pas d'entrer et de sortir le meme badge plusieurs fois, et de conserver l'historique. le but de cette appli est d'éditer des cumuls d'entrées, cumuls de sortie par mois et photographie du stock en fin de mois.
Avis perso voici ce que je ferais (d'aprés ce que j'ai compris) 3 tables : CLIENTS qui liste les clients à qui l'on donne les badges BADGES qui liste les badges avec date de mise en stock, référence, état,... MOUVEMENT qui enregistre les mouvement de badges (IDBadge,IDClient,DateSorti,DateRendu,...
L'importation d'un tableau excel, c'est pour "rentrer" ponctuellement tes nouveaux lots de badge ensuite tu utilise un formulaire qui gére les entrées/sorties individuelles de tes badges, mais ce n'est qu'une idée parmis d'autre.
- pistes avec programmation : lesquelles ?
- sans programmation : l'importation d'un tableau excel ne permet pas
d'entrer et de sortir le meme badge plusieurs fois, et de conserver
l'historique. le but de cette appli est d'éditer des cumuls d'entrées, cumuls
de sortie par mois et photographie du stock en fin de mois.
Avis perso voici ce que je ferais (d'aprés ce que j'ai compris) 3 tables :
CLIENTS qui liste les clients à qui l'on donne les badges
BADGES qui liste les badges avec date de mise en stock, référence, état,...
MOUVEMENT qui enregistre les mouvement de badges
(IDBadge,IDClient,DateSorti,DateRendu,...
L'importation d'un tableau excel, c'est pour "rentrer" ponctuellement
tes nouveaux lots de badge ensuite tu utilise un formulaire qui gére
les entrées/sorties individuelles de tes badges, mais ce n'est qu'une
idée parmis d'autre.
- pistes avec programmation : lesquelles ? - sans programmation : l'importation d'un tableau excel ne permet pas d'entrer et de sortir le meme badge plusieurs fois, et de conserver l'historique. le but de cette appli est d'éditer des cumuls d'entrées, cumuls de sortie par mois et photographie du stock en fin de mois.
Avis perso voici ce que je ferais (d'aprés ce que j'ai compris) 3 tables : CLIENTS qui liste les clients à qui l'on donne les badges BADGES qui liste les badges avec date de mise en stock, référence, état,... MOUVEMENT qui enregistre les mouvement de badges (IDBadge,IDClient,DateSorti,DateRendu,...
L'importation d'un tableau excel, c'est pour "rentrer" ponctuellement tes nouveaux lots de badge ensuite tu utilise un formulaire qui gére les entrées/sorties individuelles de tes badges, mais ce n'est qu'une idée parmis d'autre.
