Algorithme CBN, comment structurer le programme ?

Bonjour,

maintenant que j'ai fini de programmer mon appli de gestion de production (gestion commerciale, stocks, qualité, prévisions, gammes/nomenclatures, of, os, ressources machines/centres/départements), je m'attaque maintenant au cœur de mon appli, le moteur de calcul des besoins nets qui va me générer mes propositions d'achat/fabrication.

J'ai plein d'idées mais je n'arrive pas à structurer comme il faut ma pensée, parce que je me dis qu'en voulant satisfaire un besoin (une commande) je vais générer des propositions qui vont à leur tour me générer de nouveaux besoins, etc..., que le besoin en composant C peut se manifester à plusieurs reprises au cours de mon traitement, auquel cas comment je regroupe les propositions pour en avoir un minimum (c'est là qu'interviennent les politiques d'approvisionnement/lotissement). Bref, je vois bien qu'il y a un coté récursif, mais je n'arrive pas à dégrossir sur le papier une structure de programme, même en pseudo-code, qui me permette déjà de me lancer dans la programmation de mon module, quite à le rendre plus performant/fin ensuite.

Alors, j'ose vous demander si vous auriez des idées pour mettre en place une telle fonctionnalité, si certains ont déjà bossé sur un tel projet et peuvent m'apporter un peu d'aide.

Merci à vous

Bonjour,

réfléchis y en terme de produits finis et de composants. Tu devrais alors voir des arbres que tu dois parcourir en profondeur.
Bref, tu prends les éléments finis (tête) et si tu as besoin de recommander, alors tu passes à ses composants (feuilles) et tu regardes les dispos. Tu marques combien il faut que tu en réserves pour ces produits finis par rapport aux stocks et commandes. Et ainsi de suite jusqu'aux composants primaires.

bon courage,

Nicolas

Merci Nicolas pour ces premiers éléments de réflexion.

Je vois à peu près comment dégager une liste des références à commander/produire.

Maintenant il faut que je puisse positionner ces propositions dans le temps, et pour ça je crois qu'il faut se baser sur la notion de leadtime. Et le calcul du leadtime (temps mis pour produire une ressource, ou bien pour l'approvisionner via un achat) je ne sais pas bien comment l'exprimer, ça doit se faire via une heuristique ou autre, parce qu'à priori, le leadtime est déconnecté de la qté, alors je vois mal comment ça peut fonctionner. Imaginons un leadtime de 50 jours (exemple), dans la pratique mon CBN pourrait utiliser le leadtime pour rétroplanifier une proposition de fabrication, de 50 jours pour un OF de 2000 pièces, mais aussi de 50 jours pour un OF de 10 pièces !!

Evidemment, je pourrais aussi simuler la rétroplanification de façon précise de chaque proposition, comme ça j'aurais une date de début vraiment précise, et qui correspondrait bien au nombre de pièces fabriquées (j'ai déjà cette fonction de rétroplanification des opérations d'un OF dans mon module FAB, ça me sert à avoir un suivi de fabrication bien précis) mais ça prendrait un temps fou, donc j'imagine que c'est pour ça qu'on utilise le leadtime (temps global de fabrication d'un produit, vis à vis d'une gamme opératoire)

Bref, si quelqu'un a des notions bien avancées de gestion, ordonnancement, etc... (peut-être toi Nicolas ?) il est plus que bienvenu pour m'apporter quelques définitions, et règles dans le domaine des erp...

Merci

Faute de réponse voici des petits cailloux à apporter à la réflexion :

Tout le problème réside dans l'abstraction des composants.
On peut considérer qu'un composant et un produit finit sont tout deux des états différents de composants, le produit fini ayant simplement un statut terminal.
On peut connaitre le stock d'un composant : voici la notion de quantité.

L'avancée dans la fabrication montre que les composants sont transformés en un composant d'étape suivante. La fabrication manifeste donc la relation entre des composants 'parents' et un composant enfant du processus.
Une fabrication indique la quantité consommée de parents pour la fabrication de l'enfant, le poste de travail utilisé et le temps nécessaire. On voit ici la notion de "débit" de la fabrication.
Evidemment il y faudra certainement tenir compte d'un ensemble de bornes sur ces notions et rendre le système plus souple.
on peut avoir un temps minimum, maximum et moyen de fabrication. Ce temps peut être découpé en phases : mise en oeuvre, réglage, production.

A ce stade, on sait déterminer, pour un composant à produire :
- Quels sont les composants et fabrications qui vont entrer jeux
- Calculer une consommation

En priorisant les fabrication entre elles et déterminant des règles de gestion pour être en mesure de régler le cas des des priorité égales on devrait arriver à être capable de :
- calculer un temps de production.
pour enfin :
Planifier une fabrication unique.

Viendra évidement ensuite un second étage qui consistera à gérer plusieurs productions en même temps en organisant les fabrications simultanée de composants communs entre deux productions.

PS : l'approvisionnement de composants depuis l'extérieur (achats) peut être assimilé à une fabrication qui transforme le composant "externe" en composant "interne" et manifester une durée d'approvisionnement utile à vos calculs.

Bon courage,

Bonjour,

je n'ai pas pu répondre à tes questions car j'ai dû soldé un tas de problèmes avant de partir en vacances.

Je ne suis malheureusement pas au point au niveau gestion de prod, ordonnancement etc ... car je n'ai pas touché à ces sujets depuis 14 ans et cela m'est sorti de la tête ... C'est le problème d'être en entreprise et non plus en SSII !

Merci à Romuald de filer un coup de main et autres pour plus tard.

Nicolas

Bonjour Nicolas, R&B.

@R&B : en fait tout cela je l'ai déjà bien assimilé vu que j'ai déjà tout la partie gamme/nomenclature et fabrication avec création d'un OF et rétroplanification des opérations d'après une échéance d'ordre.

Ce qui me posait problème, c'était d'imaginer comment le CBN parcourt un horizon donné et calcule l'évolution du stock d'un article en fonction des entrées sorties qui peuvent survenir chaque jour. Et d'avoir des propositions qui soient le plus précises possible, sans que cela ne pénalise la performance de la fonction.

Maintenant que j'ai le nez bien dedans depuis une semaine, je suis parvenu à déterminer une ossature correcte, que je partage ici (j'ai volontairement occulté certaines parties du code qui n'étaient pas essentielles pour la compréhension) :

Code:

---

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 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209

PROCEDURE calculBesoinsNets(aid est un entier = 0)   SI aid = 0 ALORS   // premier appel de la procédure avec argument aid = 0   // purge des tables qui vont contenir les propositions (OF, OA, OP positionnées dans le temps, et nomenclature d'OF)   // dans une structure de tableau d'objets références avec propriétés de rang dans la nomenclature // je mets l'ensemble A des articles qui ont un besoin "brut" (commande, prévision, stock sécu, sont composants de nomenclature d'OF insuffisamment approvisionnés) // et je mets les composants de nomenclatures des articles de A dans ce même tableau de références // en même temps que j'alimente le tableau, je m'arrange pour associer à chaque article son rang de nomenclature le plus élevé (le plus profond dans l'arbre) // et je trie le tableau par ordre croissant du rang de nomenclature des articles // ça me permet de lancer le véritable calcul CBN en ne parcourant le tableau qu'une seule fois, de façon ascendante   POUR chaque element A du tableau T   calculBesoinsNets(A)   FIN   SINON   // pour un article donné   // on part de son stock virtuel initial (avant même d'avancer dans le temps) // on calcule toutes les entrées/sorties pour la période avant aujourd'hui strictement (aujourd'hui exclu) // stock = stock actuel + qté au contrôle + réceptions OA (existants ET proposés) en retard mais dues (échéance de livraison < aujourd'hui) // + réceptions OF (existants et proposés) en retard mais dues (échéance de l'ordre < aujourd'hui) // - stock secu - retard de livraison de commandes client (délai de livraison < aujourd'hui) // - besoin en composants sur des opérations en retard d'OFs parents (existants ET proposés)   // ????? est-ce qu'on s'occupe de la prévision pour le stock virtuel initial ?????? // => option choisie : les prévisions passées non complètement honorées n'ont pas d'impact sur le CBN   // calcul du stock virtuel initial stock_virtuel est un numérique = stockVirtuelInitial(aid) balance_jour est un numérique   // on récupère dans l'article, les infos de stock sécu, politique d'appro, etc... HFiltre(art, art_id, hValMin, hValMax, "art_id = " + aid) HLitPremier(art) stock_secu est un numérique = art.art_stock_secu gamme_correcte est un numérique = art.art_gamme_nmcl_correcte politique est un entier = art.art_appro periode est un entier = art.art_periode_appro taille_de_lot est un entier = art.art_lot_appro delai_appro est un entier = art.art_delai_appro HDésactiveFiltre(art)   q est un numérique p est un numérique = 0 echeance est une Date flag est un entier = 0 dTemp est une Date = DateDuJour() dTemp..Jour -= 1 // hier     // en fonction de la politique de réappro // - si égal au besoin : à chaque fois qu'on passe en négatif on génère une proposition // et on va comme ça jusqu'au bout de l'horizon   // - si par lots : on attend de dépasser la taille de lot pour générer la proposition // et on relance le cbn sur le même article // si on atteint l'horizon avant de dépasser la taille de lot // on fait quand même une dernière proposition égale à la taille de lot mais on ne relance pas le CBN   // si par période : on attend de passer en négatif pour entamer la période // (cela marque la date d'échéance de l'ordre qui sera proposé) // et on déroule la période (ou bien on atteint l'horizon) // si la période est atteinte, on génère une proposition et on relance le CBN sur le même article // si on atteint l'horizon avant la période, on génère une proposition mais on ne relance pas le CBN //     // ON AVANCE JOUR PAR JOUR (jusqu'à atteindre l'horizon saisi dans l'interface) // ON commence à la date de "hier"   q = stock_secu - stock_virtuel   TANTQUE dTemp <= SAI_horizon   SI q > 0 ALORS   // on marque le date de début du besoin (pour les politiques d'appro par lot et par période) SI flag = 0 ALORS echeance = dTemp flag = 1 p++ // on entame la période que dont on souhaite couvrir le besoin (si politique par période) FIN   SI flag = 1 ALORS p++ FIN   SELON politique   CAS 1: // égal au besoin   // on génère une proposition de qté = q pour échéance = dtemp // ça permet juste de remettre le stock au niveau du stock sécu // potentiellement, il est possible que dès le lendemain le stock soit déja consommé et nécessite un réappro // auquel cas, la politique d'appro est mal choisie, il faut passer en appro par période (et déterminer la période) // ou par lot (avec lot dimensionné suffisamment grand pour couvrir le besoin d'une période à déterminer)   PROPOSE(aid, dTemp, q, Val(gamme_correcte), delai_appro)     CAS 2: // par lot   SI (q >= taille_de_lot) ALORS   // on génère n propositions avec q = taille_de_lot pour échéance = date où le besoin a commencé a être identifié mais inférieur au lot   nb = ArrondiSupérieur(PartieEntière(q / taille_de_lot))   POUR i = 1 _A_ nb PROPOSE(aid, echeance, taille_de_lot, Val(gamme_correcte), delai_appro) FIN   // et on relance le CBN sur le même article pour détecter un éventuel autre besoin (ultérieur) et générer un nouveau lot SI dTemp < SAI_horizon ALORS calculBesoinsNets(aid) FIN   RETOUR // pas besoin d'aller plus loin   SINON   SI dTemp = SAI_horizon ET q > 0 ALORS   // on a atteint l'horizon et on a quand même un besoin (inférieur à la taille de lot) // on génère quand même une proposition de qté = taille_de_lot pour échéance = début du besoin PROPOSE(aid, echeance, taille_de_lot, Val(gamme_correcte), delai_appro)   FIN   // sinon on ne fait rien // la taille de lot n'est pas atteinte et on n'est pas au bout de l'horizon // on va un jour plus loin   FIN   CAS 3: // par période   SI p = periode ALORS   // on a atteint la période pour laquelle on souhaite couvrir le besoin // on génère une proposition égale au besoin de la période   PROPOSE(aid, echeance, q, Val(gamme_correcte), delai_appro)   // et on relance le CBN sur le même article pour détecter un éventuel autre besoin dans la période qui suit SI dTemp < SAI_horizon ALORS calculBesoinsNets(aid) FIN   RETOUR // pas besoin d'aller plus loin   SINON   SI dTemp = SAI_horizon ET q > 0 ALORS   // on a atteint l'horizon mais pas la période // on a quand même un besoin // on génère quand même une proposition de qté = q pour échéance = début du besoin // cette proposition couvrira une période inférieure à la période d'appro // du fait qu'on a atteint l'horizon de calcul du CBN   PROPOSE(aid, echeance, q, Val(gamme_correcte), delai_appro)   FIN   // sinon on ne fait rien // la période n'est pas atteinte et on n'est pas au bout de l'horizon // on va un jour plus loin   FIN   AUTRE CAS   FIN   FIN       dTemp..Jour ++   SI dTemp < SAI_horizon ALORS   // puis on calcule l'évolution du stock_virtuel de l'article (pour le jour qui suit) // en tenant compte des différentes entrées sorties qui peuvent survenir // livraison de commande, reception d'achat, réception de proposition d'achat // reception d'of ou de pof // besoin sur un OF parent (demande à approvisionner en composant aid) ou sur POF     balance_jour = BalanceJour(aid, dtemp) q -= balance_jour     FIN     FIN // (horizon atteint)     FIN

---

Vous devriez avoir compris que je gère 3 politiques d'approvisionnement (certains diront lotissement) différentes :

- egal au besoin (en anglais FOQ) : on génére une proposition égale au besoin, éventuellement on précise des mini/maxi/multiple de commandes pour affiner les propositions (je n'ai pas encore intégré ces concepts)

- par lot (LFL) : les ordres proposés sont découpés en lots d'une certaine taille. Donc j'avance dans le temps jusqu'à avoir atteint un besoin au moins égal à la taille de lot

- par période (POQ) : en général on adopte cette politique pour les articles achetés. On parcourt les jours jusqu'à ce qu'un besoin s'exprime, cela marque le début de la période couverte, on avance d'une durée égale à la période, et on génère un ordre pour le besoin identifié sur la période.

La fonction PROPOSE permet de planifier une POF ou une POA, selon que l'article a une gamme/nomenclature correcte ou non. Si pas de gamme correcte, alors on passe un achat, sinon c'est une production interne. Dans le cas d'une POF, cette planification créé également tout le jalonnement "temporel" des opérations et des composants nécessaires aux opérations (nomenclature POF).


J'ai testé sur un horizon court (15 jours) et avec quelques commandes, OF, stock sécu, etc... tout ça fonctionne bien.
Mais ça se gâte quand j'augmente l'horizon de calcul, puisque il y a des calculs relativement couteux en temps, chaque jour de la boucle de parcourt de l'horizon....
Là je comprends tout l'intérêt des procédures stockées sur serveur, donc je suis en train de transférer certaines requêtes interne à ma fonction CBN vers des procédures stockées sur mon serveur sql.

Mais j'espère encore trouver moyen d'optimiser d'avantage. Je ferai des tests de performances que je vous communiquerai bientôt.

Je suis évidemment à l'écoute de toutes vos remarques et commentaires qui pourront m'aider à perfectionner mon outil.

Merci

Bonjour,

Votre exemple démontre cette compréhension. En effet, la gestion d'horizons de plus en plus lointains augmente le temps de traitement de manière exponentielle.
L'optimisation va consister à ramener ce temps à une droite... et donc à n'avoir qu'un nombre relativement connu d'opération par unité de temps.

Pour le travail d'optimisation, il peut être intéressant de poser les formules de calculs/cumuls et d'en tirer les membres. Parmi ces membres, identifier les valeurs saisies ou calculées, de celles qui sont lues dans le systèmes.
En plaçant toutes ces entrée de part et d'autre d'une grille, et en indiquant la formule en intersection, vous en tirerez une matrice indiquant pour chaque calcul, quelles sont les valeurs à lire ou à saisir/calculer.
Au passage, une analyse de votre algorithme vous permettra de déterminer le nombre d'appel de ces calculs avec à chaque fois un "niveau" de paramètre. Vous pourriez aussi analyser comment ces paramètres sont calculés et ajouter ces données à votre matrice.
Vous serez donc en mesure de "visualiser" votre ensemble de calcul et donc de séparer les calculs des opérations de lecture.
L'enjeu est alors de rassembler les informations de lectures en début de processus dans un espace temporaire et volatile dédié et dont l'accès est organisé de manière à faciliter les calculs.
en effet, normalement les données sont organisée pour être enregistrée avec vérification de leur intégrité. Cette fois les données lues sont intègres, vous pouvez porter votre attention sur l'optimisation des accès depuis les calculs.

Il est possible d'accompagner la lecture des informations de pré-calculs dont le résultat peut être ajouté à cet espace de données.

Il est possible d'utiliser les temps de moindre activité pour préparer cet espace de données via un automate. La phase finale ne se résumera alors qu'en une succession de calcul à partir de ces données préparées et structurées pour la vitesse.

On le mesure enfin : jour après jour, la production étant limitée (temps homme/machine, ressources etc), le volume de donnée préparées va être relativement constant.
Les calculs qui les exploitent suivent... on arrive donc, à limiter l'effet "exponentielle" des temps de lecture.

Bonjour,

merci pour cette participation. Je ne vous cache pas que je n'ai pas trop compris le coup de la matrice !

Pour l'instant j'ai réussi à ramener le calcul à moins d'une minute pour la génération d'une quarantaine de propositions sur un horizon d'un mois (une vingtaine de références concernées, 4-5 commandes dispersées, quelques stocks sécu, et 5-6 ofs en cours).

Quoi qu'il en soit, je mesure bien l'intérêt de lire un minimum de chose à l'extérieur de mon appli, et donc de limiter les requêtes vers la BD.

Mais sachant que le CBN génère de nouvelles données au cours de son déroulement, je n'ai que 2 options :
- soit je gère tout dans sql server, et toutes mes tables de propositions d'of (pof), d'oa (poa), et les nomenclatures de pof, etc... sont complètement sous sql server donc à chaque jour je dois relancer ma procédure stockée pour qu'elle intègre les variations éventuellement engendrées par les POF/POA/...
- soit je rapatrie tout l'existant au jour j0 (stock actuel, qté au contrôle, livraisons prévues, réceptions OA OF prévues, besoins sur OF, prévisions, etc...) localement dans une table invisible et les propositions faites par le CBN viennent s'accumuler dans cette table cachée, et tous les calculs de stock virtuel à un jour j se font sur cette table

Pour l'instant moi je suis instinctivement parti sur l'option 1 parce que je voulais avoir quelque chose de fonctionnel rapidement, et ensuite seulement penser à l'optimisation.

Je pense maintenant que le mieux est de passer quelques secondes tout au début pour rapatrier dans une structure locale toutes les données "fermes" existant dans la base, et ensuite augmenter la structure locale par les propositions générées par le CBN. Ce que je ne sais pas trop faire pour l'instant c'est faire des interrogations selon des intervalles de dates sur des tables WinDev, comme si je passais une requête sql sur une table de BD, mais cette fois sur un objet Table...

Je vais me pencher sur cette nouvelle approche.

Bon voilà, j'ai maintenant une table qui contient tous les mouvements d'entrées et sorties potentielles (reliés à des commandes fermes, réceptions d'oa, of, etc...) pour tous les articles pour lesquels j'ai identifié un besoin au temps t0, ainsi que pour tous les composants de la nomenclature de ces articles (sur lesquels pourraient potentiellement se répercuter des besoins et par conséquent des propositions).

Cette table est très simple, elle est structurée comme suit :

aid # type # qte # date

et contient par exemple :

215,'LIVRAISON_CC',-2000,15/07/2014
345,'RECEPTION_OA',500,18/07/2014
etc...


Maintenant, pour un jour j donné, je dois être capable de connaître le stock virtuel (ou stock projeté) en tenant compte de ces différents mouvements d'entrées / sorties.

Mais comment faire pour filtrer facilement la table selon deux critères, l'article (aid) et la date (tout ce qui se passe avant telle date), et enfin faire la somme de la colonne qté, ce qui me donnera une balance égale au stock projeté pour le jour j.

Je dois tester si je peux lancer 2 TableActiveFiltre l'un après l'autre, le premier pour l'article, le second pour la plage de date...

Logiquement, ensuite, je devrait vite arriver au bout et me rendre compte de la performance

Bonjour,

ça y est j'ai mis en place la version 2 (donc pas d'appel de procédure stockée externe pendant le parcourt de l'horizon), nettement plus performante, surtout quand on augmente l'horizon.

Ci dessous le temps mesuré par le module "performances" de WinDev, pour chaque exécution du CBN (V1 puis V2), en ms, l'horizon exprimé en mois.

HORIZON	V1	V2
1	56	25
2	113	42
3	165	59
4	227	76
5	284	89
6	344	105

Il me reste à tester la montée en charge au niveau du volume de données, et voir si ça tient toujours la route sur des horizons relativement conséquents...

Léger problème que je n'arrive pas à résoudre, enfin surtout à comprendre pourquoi j'ai un calcul faux.

Chaque jour, pour un article donné, je calcule son stock virtuel. Je le calcule comme étant un filtre sur une table de mouvement d'entrées / sorties TABLE_ES, sur la colonne aid (mon article) et sur la colonne date (tous les mouvements inférieurs ou égaux à un jour donné).

Voici ma fonction :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

PROCEDURE calculeStockVirtuel(aid est un entier, jour est une Date)   q est un numérique // on interroge la table table_ES   TableActiveFiltre(TABLE_ES.COL_aid,filtreEgal,aid) TableActiveFiltre(TABLE_ES.COL_Date,filtreInférieurOuEgal,jour)   q = TABLE_ES.COL_qte[ligneTotal]   SI aid = 78 ALORS Info(aid + " " + JOUR + " " + q) FIN   RENVOYER q

---

J'ai remarqué que le besoin est toujours identifié un jour trop tard, et je m'en rends compte en faisant tourner mon CBN et en débuggant sur un article en particulier (l'article 78).

La première phase du CBN collecte les mouvements rattachés à des commandes, achats, fabrication, prévision, etc... fermes, existants déjà dans le système.

Voici ce que cette première phase me ramène comme mouvements datés, pour l'article 78 :

http://img4.hostingpics.net/pics/818331phase1.jpg

Ensuite je fais tourner le CBN, jour après jour, et voici ce que me retourne la procédure calculeStockVirtuel, regardez bien au fond le résultat du filtre sur la table, en fonction de la date :

Au 20 juillet :
http://img4.hostingpics.net/pics/541028stockau20.jpg

Au 21 juillet :
http://img4.hostingpics.net/pics/784838stockau21.jpg

On voit bien que pour le 21, il identifie un besoin 2900 alors que dans le tableau la LIVRAISON_CC est pour le 20 !

Pourquoi ce comportement ? Je fais pourtant bien un filtreInférieurOuEgal sur la table ...

Pour l'instant j'ai augmenté artificiellement d'un jour la borne max de mon filtre sur la date, et ça me donne bien ce que j'attends. Mais s'agit-il d'un bug de la v17 ou bien d'une erreur qqpart dans mon code ?

Merci pour votre aide.

Bon finalement je m'en sors en leurrant le filtrage comme indiqué dans mon dernier message.

A force d'utiliser mon cbn, je me rends compte que certaines propositions ne sont pas forcément très pertinentes, surtout quand on est dans le retard.

Je parcours systématiquement, pour chaque article, une plage de dates allant de aujourd'hui jusqu'à un certain horizon (ex : de aujourd'hui au 08/09/2014)

Cas illustrant une certaine incohérence :

Soient A et B deux articles dont le stock est nul, manipulés en pièce (unité de mesure = la pièce).
A est approvisionné par FOQ (qté fixe égale au besoin)
B est une fourniture achetée, également en FOQ (pour l'exemple), dont le délai d'appro est de 7 jours calendaires
Une unité de A est fabriquée à partir de une unité de B (autrement dit B est dans la nomenclature de A, lien = 1 pour 1)
J'ai sur A un stock de sécurité = 500 pc

Je commence mon parcours du temps pour A (dt = aujourd'hui, tant que dt <= horizon .....).
J'identifie dès aujourd'hui un besoin pour A (= mon stock sécu de 500pc), donc je rétroplanifie un OF (F1) de 500pc dont l'échéance sera = aujourd'hui
La première conséquence est que cela va positionner dans le passé (disons 10 jours avant l'échéance de F1) un besoin en B de 500pc (la date exacte dans le passé dépend du moment où sera nécessaire B dans la gamme de fabrication de A, je ne m'étends pas là dessus)

Ensuite, quand mon cbn va s'intéresser au cas de l'article B, il va prendre en compte ce besoin antérieur de 500pc (pour fabriquer A) , et me proposer un achat de 500pc pour échéance = date courante dans le parcourt de l'horizon (= dt = aujourd'hui), et rétroplanifié de 7 jours (délai d'appro)

Au final, je vais avoir un achat de B que je vais recevoir le même jour où je devrai avoir fini mon OF de A !!

Et je ne peux pas repousser mon OF de A en conséquence de mon achat de B, car si on autorise cela, potentiellement, tout OF repoussé ne respectera plus le timing des besoins qui justifiaient précisément sa position dans le temps !

Je pense qu'il faut établir une règle de gestion et s'y tenir, mais je ne sais pas du tout comment cette problématique est appréhendée dans les ERP classiques. Une solution simple qui me vient immédiatement serait de marquer visuellement (en rouge par exemple) toute proposition (POF, POA) nécessitant d'être déclenchée dans le passé, ce qui avertirait l'utilisateur d'éventuelles incohérences dans les propositions relatives aux besoins en retard...

J'avoue que je ne sais pas trop trancher la question, je vais mettre mon module en standby le temps de sortir un peu la tête du bocal, glaner un peu d'info à droite à gauche, et y réfléchir à tête reposée.

Ceci étant, merci à quiconque m'apportera quelques éléments de réflexion.

Bonjour, je continue mon monologue (:mouarf: ne pas le prendre mal)

j'ai tout simplement simulé le cas précédent sur notre vieille gpao progress, et voici ce que ça donne :

http://img4.hostingpics.net/pics/289668testmfg1.jpg

Donc, l'article A est en FOQ ⁽¹⁾ (à noter que je me trompais dans ma définition du FOQ, que je confondais avec LFL, de l'anglais Lot For Lot, faux ami car signifie "au cas par cas", "égal au besoin"), en l'occurrence je veux des propositions découpées par qté fixe de 500 ⁽³⁾

J'ai d'ailleurs un stock sécu de 500 ⁽²⁾ qui va me déclencher tout de suite un besoin, puisque mon stock est de zéro.

Le système s'appuie sur un leadtime de fabrication de 10 jours ⁽⁴⁾, issu d'une moulinette exécutée de temps en temps via un autre menu, qui calcule le temps de la gamme de fabrication. On peut d'ailleurs forcer ce délai manuellement (ce que j'ai fait). Perso, dans mon système, je me fais ch*** à simuler la rétroplanification réelle de l'ordre (POF, POA) pour retrouver sa date de lancement exacte, je ne m'appuie pas sur un délai "moyen" qui peut être complètement dans les choux selon la qté proposée !

Bref, on s'aperçoit que le système propose un OF dont l'échéance est le 09/07/2014 (=aujourd'hui) ⁽⁶⁾, de 500pc (pour combler le stock sécu), qu'il faudrait exécuter le 25/06/2014 ⁽⁵⁾.

Maintenant je regarde ce qu'il propose pour le composant B :

http://img4.hostingpics.net/pics/810668testmfg2.jpg

J'ai mis B en appro LFL (cas par cas, égal au besoin)⁽⁷⁾, avec un délai d'achat de 7 jours ⁽⁸⁾
On voit qu'il a positionné au 25/06 un besoin de -500 (nécessaire dès le lancement de la fabrication de l'OF de A)
Pour autant, l'échéance de la proposition d'appro de B est calculée au 09/07/2014 (=aujourd'hui) ⁽¹⁰⁾, avec une date de passage de commande rétroplanifiée de 7 jours, soit égale au 02/07/14 ⁽⁹⁾

CONCLUSION : On se retrouve avec 2 propositions, les deux se terminant à la date d'aujourd'hui, alors que l'OF de A a besoin de composants B dès le 25/06/2014 !

Si d'autres personnes peuvent simuler ce petit exemple, et me dire le résultat obtenu sur d'autres gpao, votre contribution serait très appréciée.

Merci

PS : le titre de la discussion n'étant plus forcément conforme à ce qu'elle est devenue, un modérateur pourrait-il svp le redéfinir en "CBN Calcul Besoins Nets, fonctionnement, optimisations" ?

Citation:

---

Envoyé par bvadam

Mais comment faire pour filtrer facilement la table selon deux critères, l'article (aid) et la date (tout ce qui se passe avant telle date), et enfin faire la somme de la colonne qté, ce qui me donnera une balance égale au stock projeté pour le jour j.

Je dois tester si je peux lancer 2 TableActiveFiltre l'un après l'autre, le premier pour l'article, le second pour la plage de date...

Logiquement, ensuite, je devrait vite arriver au bout et me rendre compte de la performance

---

Pour parcourir un même fichier selon deux filtres il existe une solution : monter un second contexte sur ledit fichier.
Pour ce faire vous devez déclarer une source de données et brancher ce fichier sur la source de donnée via un HDeclareExterne().
Du coup vous pourrez adresser votre filtre sur le contexte fichier normal... et faire vos recherches/filtres sur la source de données (en fait le même fichier mais branché selon un autre contexte).
Ce doublage d'accès est très pratique. Pensez à libérer la source de données en fin de traitement via HAnnuleDeclaration().