Travail sur une seule Table de mouvements Stock (entrées et Sorties)

Version imprimable

21/09/2015, 22h14
nabilG

Travail sur une seule Table de mouvements Stock (entrées et Sorties)

Bonsoir,
Je bloque sur une requête:
Je travaille avec une table de mouvements du Stock:
ID_ART :Identité article
LOT : Lot
TMV ;Type de mouvement 0 si entrée stock et 1 si sortie stock
QUANTITE: Quantité

Pour un ID_ART, Il y'a toujours une QUANTITE (Qe) entrée dans le stock avec N° LOT unique (TMV = 0). On peut faire sortir ce lot en plusieurs fois. c.à.d on peut trouver plusieurs ID_ART avec ce N° de LOT et des QUANTITES différentes Qs1,Qs2,Qs3... (et TMV = 1) mais la somme de ces quantités Qs ne doit jamais dépasser la quantité entrée Qe
C'est ce que je veux vérifier car je soupçonne que mon programme en C# développé par moi même m'a induit dans cette erreur.
Merci d'avance.
22/09/2015, 03h10
alassanediakite
Salut
Il faut préciser le SGBD utilisé.
Cela faisable par check (contraint de validation) sur Qs en deux temps
1. une fonction qui calcule le stock restant de Qe
2. dans le check, comparer ce stock au Qs
... ou par trigger...
Si c'est ACCESS, il faut passer par VBA (Version<=2007) et ou macro de données (Version>=2010)
@+

Ou comme ceci

Code:

1
2
3
4
5
6
7
8
 
SELECT SUM(SUBQ.MONT)                        
FROM (SELECT CASE                            
             WHEN TMV = 0 THEN QUANTITE
             ELSE QUANTITE * -1                  
             END AS MONT                     
      FROM STOCK) AS SUBQ                
;

Ou encore une CTE qui reprend le contenu de la sous requete ci-dessus, puis une requete sur cette CTE

22/09/2015, 10h03
StringBuilder

Bonjour,

Si votre SGBD supporte les procédures stockées, vous devriez faire ce traitement de création du stock initial puis décrémentation des stocks avec une procédure stockée, et non en C#.

En effet :
- Pour avoir des données à jour pour faire vos tests, vous devez lire plusieurs fois la table des stocks
- Et la mettre à jour potentiellement plusieurs fois

Niveau performances, il vaut mieux que tout soit fait dans un seul lot, côté serveur.

Aussi, si demain votre méthode de picking doit changer, et que vous avez plusieurs programmes qui peuvent en faire, vous allez devoir faire évoluer plusieurs programmes. Avec une procédure stockée, vous n'avez besoin de faire évoluer que cet unique bout de code pour que tous les programmes en bénéficient en même temps.

Un exemple classique :

Aujourd'hui, vous avez deux lots, avec Qe - sum(Qs) = 4 et 10, respectivement.

Vous voulez faire un picking de 8.

Plusieurs solutions :
- Votre programme recherche le lot qui a au moins 8 en dispo, et vous le décrémentez
- Votre programme détecte que le lot le plus ancien n'a que 4, et vous affichez un message "vous devez prendre 4 unités max, avant d'en prendre dans un autre lot"
- Votre programme pick 4 dans le lot le plus ancien, puis 4 dans le lot le plus récent.

Si vous souhaitez faire évoluer le traitement, il faut mieux le faire dans un seul endroit.

Maintenant, même chose, avec un picking de 12 : idem, il va falloir améliorer tout ça. Autant le faire à un seul endroit.

Ceci n'empêche pas la validation CHECK finale : dont vous pourrez certainement refactoriser le code avec votre procédure (vue qui ramène Qe - Sum(Qs) pour chaque lot par exemple, etc.)