Discussion :

[coolirc]

Bonsoir a tous

je développe depuis quelques temps une application de gestion du parc informatique pour m'aider a mon métier d'informaticien
le but de mon application est de gérer le parc informatique les affectations ajout du matériel informatique ajout d'un agent ... etc .

je suis arrivé aux consommable mais apparemment d’après un ami la gestion du consommable devrais être comme une gestion de stock ce qui veux dire une gestion des entrées et des sorties du matériels consommable.

donc pour la table consommable je veux un petit coup de pouce ou bien des idées pour comment créer ce genre de table .

j'ai déjà fait une petite recherche sur Google j'ai trouver comme idée ceci :

une table produit ( consommable)
une table entrée et une table sortie .

et déterminer les entrées et les sorties a partir de la table produit .

j'ai déjà créer ma table consommable avec les champs :

id_consommable , type , marque , QTE , DATE_Entree , DATE_Sortie , Fournisseur , et j'ai relié ID_Agent pour qu'en suite j'indiquerai qui est la personne qui a pris le consommable .

pour la table entrée et sortie je ne sais pas quoi mettre exactement

une petite aide pour la création de la table et une explication sur comment fonctionne le processus serais aimable de votre part Merci
et a bientôt.

[SergioMaster]

Bonjour,

Après avoir fait une recherche de tes messages et retrouver le SGBD utilisé : Firebird 2.5 <= ce qu'il serait bon d'indiquer chaque fois que tu crées une nouvelle discussion BDD

id_consommable
type
marque
QTE, // Stock
DATE_Entree // date de dernière entrée
DATE_Sortie // date de dernière sortie
Fournisseur // ??? il y a une table fournisseur , s'agit-il du dernier fournisseur

mais peut être préféreras tu une structure différente avec

QTE_INVENTAIRE,
CUMUL_SORTIE,
CUMUL_ENTREE,
QTE COMPUTED BY (QTE_INVENTAIRE-CUMUL_SORTIE+CUMUL_ENTREE)

Plutôt qu'une table Entrée et une Sortie , pourquoi pas plutôt une table mouvements ? (c'est ce que j'utilise dans ma gestion de stocks)

il est facile ensuite d'utiliser un indicateur pour indiquer si c'est une sortie ou une entrée ou encore un inventaire, une sortie/entrée d'ajustement etc...

id_consommable
type_mvt // (-1,0,1) Sortie,Inventaire,Entrée
id_Agent
DateMvt
Qte

tu peux ensuite utiliser des Triggers lors de l'insertion d'un mouvement pour mettre a jour la table Consommables ainsi , pas besoin de faire de calculs dans le programme

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE TRIGGER AI_MOUVEMENT FOR MOUVEMENTS
ACTIVE AFTER INSERT POSITION 0
AS
BEGIN 
IF (NEW.DATEMVT IS NULL) THEN NEW.DATEMVT=CURRENT_DATE; // au cas où
IF (NEW.TYPEMVT=0) 
   THEN UPDATE CONSOMMABLES SET QTE=NEW.QTE WHERE ID_CONSOMMABLE=NEW.ID_CONSOMMABLE;
IF (NEW.TYPEMVT=-1) THEN UPDATE CONSOMMABLES SET QTE=QTE-NEW.QTE, DATE_SORTIE=NEW.DATEMVT WHERE ID_CONSOMMABLE=NEW.ID_CONSOMMABLE;
IF (NEW.TYPEMVT=1) THEN UPDATE CONSOMMABLES SET QTE=QTE+NEW.QTE, DATE_ENTREE=NEW.DATEMVT WHERE ID_CONSOMMABLE=NEW.ID_CONSOMMABLE;
END;

[coolirc]

ok Merci

donc pour résumer

une table consommable

une table mouvement

et a quoi sert ce champ la : QTE_INVENTAIRE,

pour le fournisseur j'ai pas encore mis de table fournisseur juste pour indiquer quel fournisseur a ramener ce produits

sinon suggère tu une table fournisseur et la relié a la table consommable par un id_fournisseur ?

[SergioMaster]

et a quoi sert ce champ la : QTE_INVENTAIRE,

c'est une autre manière de gérer les stocks
lorsque l'on fait un inventaire alors QTE_INVENTAIRE=la Quantité et les CUMUL_ENTREES et CUMUL_SORTIES sont mis à 0
il est bon dans ces cas là de rajouter Date_Inventaire

Ainsi il est très facile de connaitre la consommation après inventaire (sans avoir à rechercher dans les mouvements) => rapide

sinon suggère tu une table fournisseur et la relié a la table consommable par un id_fournisseur ?

perso : oui . Tu peux avoir plusieurs fournisseur pour un même consommable , des prix et conditions différentes etc...
en plus cela permet de gérer un carnet d'adresse (pratique lorsqu'il faut commander) . Enregistrer le Prix Unitaire Achat dans les Mouvements permettrait en plus d'obtenir un Catalogue

bien sur cela devient un gestion de stock de plus en plus fine (et donc lourde) ce qui n'est peut être pas ton objectif

[chekkal]

Bonjour,
Moi je te proposerai de créer 3 table
Table Achat
Table Vente
Table Stock

le Stock sera calculé à la demande (Achat-Vente)

[SergioMaster]

Bonjour,
Moi je te proposerai de créer 3 table
Table Achat
Table Vente
Table Stock

le Stock sera calculé à la demande (Achat-Vente)

@checkal
au vu des galères que tu as eu au niveau de tes requêtes , tu ne crois pas que ma solution est plus adaptée ? Bien sur on peut faire une table Achat et une table Vente et des Triggers pour incrémenté/décrémenté le Stock et ce à la place d'une table Mouvements . Mais le Stock à la demande ... là tu pénalises le temps de réponse et si jamais tu veux calculer des PMP bonjour la galère

[coolirc]

Merci pour les réponses les amis je n'ai pas encore eu le temps de tester la solution proposé par Sergio dés que j'aurais le temps je vais l'essayer et voir le résultat et vous tenir au courant Merci a tous

[coolirc]

Bonsoir a tous je reviens vers vous pour exposer mon problème

j'ai fini par créer ma table consommable comme suit :

table consommable :

ID_CONSOMMABLE
TYPE
MARQUE
DATE_ENTREE
DATE_SORTIE
ID_AGENT
ID_FOURNISSEUR
QTE_INVENTAIRE
CUMUL_SORTIE
CUMUL_ENTREE
QTE


table Mouvements :

ID_MOUVEMENTS
ID_CONSOMMABLE
TYPEMVT
DATEMVT
QTE
ID_AGENT


j'ai essayer ensuite d’intégrer le trigger proposé par Sergio j'ai le message d'erreur :

This column cannot be updated because it is derived from an SQL function or expression.
attempted update of read-only column.

d’après une recherche sur Google sur le site de firebirdsql ça dit ça

This error message might show up when you try to update a computed column. Since such column is computed, you cannot write values directly into it. If you really need a specific value, you need to change the computed source.

j'ai pas trop compris ce que ça veux dire donc je reviens vers vous

j'ai corriger le trigger en renommant consommables vers consommable .

Merci

[chekkal]

bonjour à tous,
@sergio, je sais que ma méthode est plus lente mais elle est plus efficace(pratique). j'ai déjà travaillé avec la méthode "table inventaire" et pour moi c'est beaucoup de contrôle à faire

-contrôler les modifications sur les achats et les ventes.
-contrôler la suppression d'un achat ou d'une vente.
-contrôler les factures d'avoir
-et plus surprenant encore les problème de coupure de courant electrique si par exple après validation d'un achat et avant de mettre à jour la table inventaire il y a coupure de courant

@coolric, c'est simple le trigger contient une modification sur un champs calculé(computed).

[SergioMaster]

j'ai pas trop compris ce que ça veux dire donc je reviens vers vous
j'ai corriger le trigger en renommant consommables vers consommable .

Le mieux , serait peut être que tu fournisses les DDL des tables et du trigger
de plus , c'est plus un "problème" Firebird que Delphi et donc poster sur le Forum HadHoc pouurait être mieux (moins déroutant pour un Delphiste

@Checkal tu ne crois pas que mon expérience en ce domaine est suffisante ?
ça fait bientôt 16 ans que mon logiciel "tourne" avec cette structure de table , j'ai déjà eu tout ces problèmes cités et d'autres depuis déjà bien longtemps !
a) un bon principe d'analyse pour les contrôles , c'est toujours de les faire à la source : donc à la saisie
b) les coupures de courant se règle grâce a un onduleur , un serveur sans onduleur est un pistolet chargé sur la tempe
c)

après validation d'un achat et avant de mettre à jour la table inventaire il y a coupure de courant

comme l'enregistrement dans la base de données déclenche le trigger sur le serveur , c'est sans fondement.

Le seul problème que j'ai pu avoir, avec à l'époque Interbase 5.1 , c'est un processeur qui surchauffait sur le serveur (obligeant de fréquente réparation de BDD) ou un réseau "merdique" (câbles non blindés proche de machines outils provoquant des parasites, remplacés par des fibres optiques) mais surtout mauvaise gestion des transactions (BDE de et erreurs de )

Checkal je pense que vous êtes encore trop attaché au BDE et Paradox , bref au mono-poste comme cela était mon cas il y a 20 ans lorsque j'ai découvert Delphi