Discussion :

[droliprane]

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

[Nicolas_Jeanneau]

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

[droliprane]

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

[R&B]

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,

[Nicolas_Jeanneau]

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

[droliprane]

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 :

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
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