Groumpf, j'ai un souci là...
 
On me demande "le total du reste à livrer à une date donnée".
 
Et là, j'ai du mal...
 
J'ai mes évènements commercieux divisées en 3 tables :
EVE : En-tête
EVP : Postes (lignes)
EVL : Ventillation dans le temps
 
EVE :
PK : codsoc, achvte, typeve, numeve (société, achat/vente, type d'évènement, numéro d'évènement)
champs :  
codeta (I : terminé, S : soldé, V : validé, B : boqué, A : annulé)
dateve (date d'application de l'évènement)
 
EVP :
PK : idem EVE + numpos (numéro du poste)
champs :
prxvdu (prix de vente)
qtecde (quantité cédée)
 
EVL :
PK : idem EVP + numlig (numéro de ligne dans le poste)
champs :
qtecde (quantité cédée - à la date)
qteliv (quantité livrée - à la date)
datliv (date de livraison - date où la ligne EVL s'applique)
 
En gros, comme vous le voyez, je n'ai pas de flag "reste à livrer". Deplus, ce n'est pas comme les stocks : c'est pas historisé. Je ne peux donc pas faire simplement avec un filtre sur la date.
 
Je pense faire :
Somme des commandes émises avant la date - Somme des livraisons effectuées avant la date
 
Sauf que là, c'est même pas la peine, je vais faire mourrir le serveur ! en plus je ne vois même pas comment faire ça simplement...
Vous auriez pas une idée lumineuse pour faire ça ?
J'étais bien tenté au début de faite qtece - qteliv sur EVL, sauf que ça me donne le reste à livrer de maintenant... et si je met un filtre sur la date, ça ne veut rien dire non plus, je peux avoir effectivement livré un relicat après le datliv ! -normalement on n'est pas censé le faire, mais ici ils le font...-

Mon patron est vraiment à la ramasse en ce moment
 
Y croit encore que les clients demandent des trucs parceque ça leur sert à quelquechose
 
J'ai dû débattre avec lui de l'inutilité du truc, et surtout, sur le fait que ce qu'il me proposait de faire ne répondais pas à la demande pendant une heure... et toujours pas de solution du coup

pourquoi faire mourir le serveur ? ton oracle sait faire des sommes

Que veut dire quantité 'cédée' ?
 
Sinon je vois pas trop ce qui gêne, il faut faire les 2 sommes et les soustraire ...

couak + beegee > ze soucy, c'est que faire les sommes sur l'intégralité des évènements jusqu'à une date donnée, c'est faire la somme de centaines de milliers de lignes.
 
 
Sinon, beegee > quantité cédée, c'est la quantité demandée.
 
Genre, je veux 25 tubes de colle.
Je reçois un premier carton de 10 aujourd'hui, et les 15 autres arrivent la semaine prochaine.
 
La ligne EVP est :
QTECDE = 25
 
Et dans EVL c'est :
DATLIV = 20060208
QTECDE = 10
QTELIV = 10
 
DATLIV = 20060215
QTECDE = 15
QTELIV = 0
 
Y'a aussi des compteurs "QTEPERDU" et autres, qui permettent d'expliquer où sont passé ceux qui étaient en QTECDE et qui ne sont pas en QTELIV. La somme de tous ces compteurs + QTELIV est toujours égale à QTECDE à la fin, sinon la livraison reste en relicat et on ne peut pas la solder.
Et la somme des QTECDE d'EVL pour un poste d'EVP = QTECDE de EVP (logique)
 
 
m'enfin de toute façon, c'est pas grave, j'ai fini par faire comprendre à mon patron le non sens de la chose, et expliqué aussi à la direction informatique chez le client. maintenant la balle est dans leur camp.
 
en effet :
- confusion entre "commande" et "chiffre d'affaire".
- confusion entre "reste à livré" et "portefeuil de commandes".
- igorance totale des flux de gescom.
- les chiffres "faux" reflètent simplement la vie des éléments dans les fluxde vente (contrairement à la finance, c'est pas parcequ'on est le mois suivant que les évènement du mois d'avant arrêtent de vivre, c'est pas figé)
 
En gros, 3 scénaris que j'ai mis au point pour illustrer le non sens de la demande :
 
Scénario I :
1) Mme Dupont demande à un magasin une pièce d'un produit.
2) Produit pas en stock. On procède à une contre-marque. Délais annoncé : 2 mois.
=> "CA" du mois = 1 pièce
=> Livré du mois = 0 pièces
=> Reste à livrer du mois = 1 pièce
3) Problème avec le fournisseur ou le transporteur. Délais allongé, ou même impossibilité d'appro.
4) Mme Dupont annule sa commande
5) Le magasin annule la contre-marque
=> "CA" mois+2 : inchangé (une annulation ne correspond pas à un avoir)
=> Livré mois+2 = 0
=> Reste à livrer mois+2 = 0
MAIS OU EST DONC PASSE LE RAL de "mois" ?
=> Chiffres foireux, inutilisables
 
Scénario II
1) Magasin commande 5 pièces
=> "CA" mois = 5
=> RAL mois = 5
=> LIV mois = 0
2) Le mois suivant, lors de la réception, le magasin se rend compte qu'un produit est cassé. Il en refuse donc 1, et en commande un nouveau.
=> "CA" mois+1 = 1
=> LIV mois+1 = 4
=> RAL mois+1 = 1
D'OU SORT CETTE COMMANDE SUPPLEMENTAIRE ?
=> Léger oubli dans la demande, il faut traîter les avoirs et retours SAV.
=> Dans tous les cas, on va observer un glissement des chiffres avec les retours, ce qui ne sera pas représentatif de la réalité (le but étant de mesurer le CA)
 
Scénario III
1) Le camion part livrer un magasin le 25 du mois. On crée l'écriture de livraison, mais on ne la comptabilise pas, puisque non confirmée
=> LIV mois = 0
=> RAL mois = 1
2) confirmation de la livraison le 5 du mois suivant. Pas de change, en GESCOM, la confirmation d'une livraison se fait à la date de livraison (donc le 25) pas le jours de réception du bon de livraison signé.
=> LIV mois+1 = 0
=> RAL mois+1 = 0
MAIS OU EST DONC PASSE LE PRODUIT A LIVRER de "mois" ?
Si on comptabilise la livraison dès le départ du camion, alors on aura le problème du I en cas de souci de transport (accident, produit perdu, etc.)
 
Bref, j'attends les retours

c'est bien ce que je dis, il est où le problème ?

le problème c'est que le serveur est déjà assez à la ramasse comme ça sans lui ajouter ça, il tiendra pas je te dis
(et de toute façon, outre le problème technique, la demande est un non-sense, donc j'ai fait un retour à l'envoyeur avec comme mention "same player shoot again" )

en l'occurrence, si c'était au final une requête à lancer une fois de temps à autre, qui fait des calculs simples sur quelques centaines de milliers de lignes, ça m'étonnerait que ça prenne plus de quelques minutes et que ça cause un tel souci.