Discussion :

[MINDONGO]

salut les gars,
j'ai une table commande, ligne commande, livraison et ligne livraison & reliquat,
quand un client passe une commande par exemple Cmd1 (art1=15,art2=10 et art3=8) et la table livraison livr1(Cmd1:art1=11,art2=10 et art3=6) la table livraison a la colonne reste a livrer reçoit (art1=4,art2=0 et art3=2) donc c'est ca qui est comme le reste a livrer, et la table reliquat (art1=4,art2=0 et art3=2)
du coup pour une prochaine commande des mêmes produits Cmd2 (art1=9,art2=6 et art3=16) il va cumuler la quantité commandée plus le reliquat.....ce qui donne comme reliquat (art1=13,art2=6 et art3=18)

ma question est de savoir comment additionner la quantité de la table reliquat avec la table livraison pour trouver le reste à livrer dans sql server

[MINDONGO]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
/*table article*/
CREATE TABLE [dbo].[bouteuil](
	[refbtl] [nvarchar](255) NOT NULL,
	[prixbtl] [int] NULL,
	[txtonag] [float] NULL,
	[stkin] [int] NULL,
	[ordern] [int] NULL)
 
	/*table Lign commande*/
	CREATE TABLE [dbo].[COMMD](
	[refcom] [int] NOT NULL,
	[date] [date] NULL,
	[refclicm] [nvarchar](255) NULL,
FOREIGN KEY([refclicm])REFERENCES [dbo].[Client] ([refcli]))
 
/*table commande*/
CREATE TABLE [dbo].[Comde](
	[refcmd] [int] NOT NULL,
	[refclicmdd] [nvarchar](255) NULL,
	[qtecmd] [int] NULL,
	[tonagecmd] [int] NULL,
	[montcmd] [int] NULL,
	[margecmd] [int] NULL,
	[gabaritcmd] [nvarchar](255) NULL,
	[zonnecmd] [nvarchar](255) NULL,
	[reliq] [int] NULL,
	[cummul] [int] NULL
 FOREIGN KEY([gabaritcmd])REFERENCES [dbo].[bouteuil] ([refbtl])
 FOREIGN KEY([refclicmdd])REFERENCES [dbo].[Client] ([refcli]) 
 FOREIGN KEY([refcmd])REFERENCES [dbo].[COMMD] ([refcom])
 FOREIGN KEY([zonnecmd])REFERENCES [dbo].[zonne] ([refzone]))
 
/*table reliquat*/
CREATE TABLE [dbo].[Reliquats](
	[refcomrlq] [int] NOT NULL,
	[reflivrerlq] [int] NOT NULL,
	[qtecomrlq] [int] NULL,
	[qtelivrlq] [int] NULL,
	[restrlq] [int] NULL,
	[gabaritrlq] [nvarchar](255) NULL,
	[zonnerlq] [nvarchar](255) NULL,
	[Clirlq] [nvarchar](255) NULL
FOREIGN KEY([Clirlq])REFERENCES [dbo].[Client] ([refcli])
FOREIGN KEY([gabaritrlq])REFERENCES [dbo].[bouteuil] ([refbtl])
FOREIGN KEY([refcomrlq])REFERENCES [dbo].[COMMD] ([refcom])
FOREIGN KEY([reflivrerlq])REFERENCES [dbo].[livr] ([reflivr])
FOREIGN KEY([zonnerlq])REFERENCES [dbo].[zonne] ([refzone]))
GO
 
 /*table ligne livr*/
 CREATE TABLE [dbo].[livr](
	[reflivr] [int] NOT NULL,
	[datelivr] [date] NULL,
	[refcomlivr] [int] NULL,
 FOREIGN KEY([refcomlivr])REFERENCES [dbo].[COMMD] ([refcom]))
GO
 
/*table livraison*/
CREATE TABLE [dbo].[livraisons](
	[reflivre] [int] NOT NULL,
	[refcomlivr] [int] NOT NULL,
	[qtelivr] [int] NULL,
	[tonagelivr] [int] NULL,
	[montlivr] [int] NULL,
	[margelivr] [int] NULL,
	[gabaritlivr] [nvarchar](255) NULL,
	[zonnelivr] [nvarchar](255) NULL,
	[restlivr] [int] NULL,
	[qtecomm] [int] NULL
FOREIGN KEY([gabaritlivr])REFERENCES [dbo].[bouteuil] ([refbtl])
FOREIGN KEY([refcomlivr])REFERENCES [dbo].[COMMD] ([refcom])
FOREIGN KEY([reflivre])REFERENCES [dbo].[livr] ([reflivr])
FOREIGN KEY([zonnelivr])REFERENCES [dbo].[zonne] ([refzone]))
GO

ma question est de savoir comment faire la soustraction de la quantité de la table reliquat avec la table livraison pour trouver le reste à livrer dans sql server

ou je veux-t savoir que serait le reste à livre a la fin de la journée sachant que la commande Num2 n'as pas été livrée

[MINDONGO]

Cmde

Livraisons

Reliquat

une autre Cmde apres livraison

[escartefigue]

Bonjour

Le reste à livrer est égal à la quantité commandée moins la somme des quantités livrées pour la ligne de commande.


Quelques remarques :
Soit votre script est incomplet, soit il est invalide : il n'y a aucune contrainte PRIMARY KEY ni UNIQUEdans votre script, de ce fait, les contraintes FOREIGN KEY ne sont pas applicables.
Déclarez des colonnes de type integer et IDENTITY comme PK.

Choisir un type integer pour un prix implique que tous les prix sont sans partie décimale, est-ce bien le cas ?

Cette contrainte
FOREIGN KEY([gabaritcmd])REFERENCES [dbo].[bouteuil] ([refbtl]).
Fait référence à une colonne varchar(255), c'est un très mauvais choix.
Ajoutez une colonne de type IDENTITY et déclarez-la comme PK dans BOUTEUIL (pourquoi ne pas avoir nommé cette table ARTICLE tout simplement ?)

[MINDONGO]

Bonjour

au niveau de la livraison oui

Le reste à livrer est égal à la quantité commandée moins la somme des quantités livrées pour la ligne de commande.

mais si jamais une nouvelle commande s'ajoutait et que la livraison n'as pas encore eu lieu

Cette contrainte
FOREIGN KEY([gabaritcmd])REFERENCES [dbo].[bouteuil] ([refbtl]).

par exemple c'est sont des bouteuil de gaz ex: 3KG

Fait référence à une colonne varchar(255), c'est un très mauvais choix.
Ajoutez une colonne de type IDENTITY et déclarez-la comme PK dans BOUTEUIL (pourquoi ne pas avoir nommé cette table ARTICLE tout simplement ?)

[escartefigue]

S'il s'agit de bouteilles de Gaz ou de tout autre fluide, alors l'orthographe appropriée est bouteille
Mais si dans cette table on peut avoir des articles d'un autre type de contenant ou sans contenant, alors le nom "article" pour la table est plus approprié.
D'une façon générale, les noms de tables doivent être au singulier. On se doute bien que chaque table contient plusieurs lignes, le pluriel est donc inutile.

Que la commande ait fait l'objet d'une, plusieurs ou aucune livraison ne change rien à l'affaire, la règle de calcul est bien celle que je vous ai donnée
ce qui donne (alias LC pour les lignes de commande et LL pour les lignes de livraison) :
Select LC.LC_QTE - coalesce(sum(LL.LL_qte), 0) as reste_a_livrer.


Je ne sais pas pourquoi vous avez barré cette remarque :

FOREIGN KEY([gabaritcmd])REFERENCES [dbo].[bouteuil] ([refbtl]).
Fait référence à une colonne varchar(255), c'est un très mauvais choix.

Le sens de cette remarque était de dire que poser une contrainte unique sur un varchar 255 est déjà pas top en soi, mais si en plus cette colonne a vocation à devenir la PK (puisque vous n'en avez pas défini) alors c'est encore pire : une PK doit être stable dans la durée et la plus concise possible. de ce point de vue du varchar(255) est à peu près ce qu'on peut faire de pire. D'où l'intérêt des IDENTITY.