1. Introduction

Les tâches concernées par l'évolution 2.0 sont une partie des tâches que vous connaissez sous le qualificatif "Tâches Week-end" ou "Tâches semaine". Il s'agit d'un ensemble de traitements programmés dans le planificateur de tâches Windows. Ces tâches ont pour vocation d'optimiser la gestion de vos stocks et de vos encours pour répondre aux besoins de vos clients.

Rappel : Lancer une tâche consiste à exécuter un raccourci, ce-dernier pointe sur l'exécutable "HeliosII.exe", le traitement à exécuter est un code tâche passé en paramètre à l'exécutable après le caractère (ex : "...\HeliosII.exe /COUV".

Les tâches "Tâches Week-end" ou "Tâches semaine" de la version 2.4 exécutent tout ou partie des traitements suivants dans l'ordre indiqué :

/PROG_PROD : Programme de production Axone.
/COUV : Calcul de la couverture,
/R_OFS : Retour couverture vers les OFs,
/DERES_PH : Dé réservation des OFS,
/PDP : Calcul des Besoins Nets Prévisionnel,
/ANA_BES: Analyse des besoins des OFs,
/COUV : Calcul de couverture,
/R_OFS : Retour OFs,
/R_OFS_PREV Retour sur les OFs prévisionnels,
/BASOR : Calcul des ouvertures et calendriers des ressources,
/PLANIF : Ordonnancement à capacité finie et infinie,
/CBA : Calcul des besoins achats.
/BILAN : Calcul des bilans,

Remarque : Le projet de réécriture ne porte pas sur les tâches matérialisées en vert de la liste ci dessus.

Des traitements chronophages et complexes qui nécessitent plusieurs heures d'exécution. Un soin particulier a été porté par l'équipe Hélios ERP pour effectuer les optimisations sur les temps d'exécution et les améliorations nécessaires pour une meilleure couverture fonctionnelle et une plus grande stabilité.

Plusieurs axes d'étude :

1. Les Temps d'exécution des tâches :

- Passage en PL SQL de certains traitements.
- Optimisation des algorithmes de traitement (/PDP).
- Regroupement de certains traitements et suppression des traitements redondants,
- Suppression de l'utilisation des IHM dans les traitements (/PDP, /DERES),
- Suppression des algorithmes pas a pas dans les traitements au profit de traitements en masse (/R_OFS et /R_OFS_PREV).

Résultats :

- - Les gains constatés en temps d'exécution de nos sites pilotes sont compris entre 45 et 50%.

2. Gestion de la mémoire : Passage en 64 bits
- Optimisation des traitements en mémoire et passage en 64 bits des traitements pour permettre d'allouer plus de 2 Go d'espace mémoire aux traitements (Voir L imites de mémoire pour les versions de Windows et de Windows Server - Win32 apps | Microsoft Learn).

Résultats en 64 bits :

- - Les crashs aléatoires des dll ont disparu=> Libération de la mémoire défaillante.
  - Il n'y a plus de limite dans le volume des données à traiter par les tâches (plus de réduction dans les horizons des traitements des calculs de la couverture et de planifications.
  - Gain entre 5 et 10 % sur les temps d'exécution selon la complexité des traitements.

3 . Prise en compte des fonctionnalités non couvertes :
- La priorité d’affectation des stocks et encours dans la couverture ne priorise plus obligatoirement le besoin d'une commande d'un article, si cet article est consommé dans une nomenclature d'un article père d'une autre commande, il peut être prioritaire si sa date de besoin intervient avant celle de la commande.
  - La priorisation dans la couverture est cohérente.
- Les rechanges dans le traitement de la couverture.
- Les indices articles dans le traitement de la couverture.
- Gestion des approvisionnements partiels dans la mise à jour de la couverture.
- Gestion des stocks par emplacement dans la mise à jour de la couverture.
- Les positionnements réels des besoins des OFs remontent dans la couverture.
  - Les tableaux de bords présentent tous les mêmes données,
  - Les calculs de dates de disponibilité sont cohérents.
- Prise en compte du négoce dans l'ensemble des tâches y compris les taches de dé réservation.
  - L’ensemble des données de la chaine achat sur le moyen terme est cohérent.
- La dé réservation inclut les OFs prévisionnels.
  - L’ensemble de la chaine achat est optimisé.

Il en résulte la livraison de nouvelles tâches en version 64 bits et 32 bits qui remplacent les tâches que vous connaissez.

Rappel : Les tâches en vert n'ont pas été impactées par les évolutions, cependant la version 64 bits de ces tâches est utilisable.

Scénario complet

/PDP : Plan de production minimaliste (Paramètre Plan de production), intègre le programme Axone.
/COUV_NEW : Couverture article, remplace /COUV.
/PDP_L : Génération des OFs prévisionnels manquants,
/R_OFS : Retour OFs, mise à jour des OF Fermes, passage en PL SQL.
/DERES_PH : Dé réservation OFS, remplace /DERES et une partie du traitement /ANA_BES qui n'existe plus.
/R_OFS_PREV : Retour sur les OFs prévisionnels, passage en PL SQL.
/DERES_PDP : Dé réservation OFS prévisionnels, Elle optimise les achats prévisionnels,
/R_COUV : Mise à jour couverture des besoins en achat et dates / statut de besoin, remplace /COUV et une partie du traitement /ANA_BES qui n'existe plus, pour éviter la redondance de traitements déjà effectués.
/BASOR : Calcul des ouvertures et calendriers des ressources.
/PLANIF : Ordonnancement à capacité finie et infinie.
/CBA : Calcul des besoins achats.
/BILAN : Calcul des bilans.

Scénario minimum

/PROG_PROD : Programme de production Axone.
/COUV_NEW
/PDP_L
/R_OFS
/DERES_PH
/R_OFS_PREV
/DERES_PDP
/R_COUV
/BASOR
/PLANIF
/CBA
/BILAN

Pour exécuter les tâches :

En 32 bits , il faut pointer sur l'exécutable que vous connaissez HeliosII.exe, la procédure reste inchangée.
- Ne bénéficie pas des apports de l'architecture 64 bits (optimisations gestion de la mémoire, gain des temps de traitement).
En 64 bits, il faut pointer sur le nouvel exécutable dédié nommé HII_TASKx64.exe.
- L'utilisation des tâches en 64 bits impose une architecture 64 bits du client Oracle.

Remarque :

La tâche /ANA_BES n'est plus utilisée.

2.Détail des nouvelles tâches 2.0.

/PDP : PDP minimaliste - Intégration du plan de production Axone

Il s'agit de la tache /PDP avec le paramètre "PDP minimaliste" activé. il s'agit d'un paramètre qui a été ajouté dans le paramétrages du Plan de Production.

Prise en compte :
- Lancements Axone.
- Suppression des OFs prévisionnels.
- Régénération des OFs prévisionnels à partir du carnet de commande.

Arrêt du calcul à la fin de la génération des OFs prévisionnels :
- Pas de nomenclature d’OFs.
- Pas de jalonnement.
- Pas de traitement des composants / matières.
- Pas de calcul de statut d’OFs.
- Pas de lancement de CBA.

Remarque concernant la tache /PROG_PROD,

A intégrer au début du process des taches avant la couverture.
Elle est inutile dans le cas ou le PDP minimaliste est mis en œuvre, ce qui est le cas de notre exemple.

Rappel concernant la tache /PROG_PROD :

Basé sur le dernier modèle Axone validé et retourné, génère un fichier de trace : PROG_PROD_OFS
- Dossier de génération paramétré dans le paramétrage du module Besoin.
Utilise l’horizon de paramétrage du module besoin
- Nombre de jour paramétré dans le paramétrage du module besoin

Permet de générer les OFs ferme.

/COUV_NEW : Analyse de la couverture, le coeur du processus

Elle remplace la tâche /COUV de la version 2.4 qui était basée principalement sur la priorisation des besoins en fonction des dates issues du carnet de commande client. Elle permet de calculer la couverture des besoins sans tenir compte des affectations existantes.

Cette nouvelle tâche utilise le Calcul du Besoin Brut (CBB) pour prioriser les besoins. Elle permet de donner au plus prioritaire des besoins d'abord le stock puis l'encours le plus avancé.

Elle apporte des gains fonctionnels notables, notamment la prise en compte des indices articles et des rechanges, qui n'étaient pas gérés dans l'ancienne tâche.

Principe du traitement :

Il est basée sur les données du Calcul des Besoins Bruts (CBB), il permet notamment de calculer les données nécessaires à la gestion Kanban.

1 : Décomposition du carnet de commande en besoins bruts articles sur tous les niveaux de nomenclature des articles du carnet de commande.
- Pas de prise en compte des stocks.
- Pas de prise en compte des encours de fabrication.

2 : Jalonnement de chaque besoin brut article des éléments de nomenclatures des articles en commande client, il dépend du contenu des gammes, il détermine le critère essentiel dans la détermination des quantités.
- Dépend du paramétrage de jalonnement généraux.
  - Cycle à la phase
    - Temps d’attente des CDC
    - Cycle inter CDC
  - Cycle Gamme
  - Temps de la Gamme
- Jalonne sur le calendrier société
- Lot maximum de lancement
- Prise en compte chevauchement

Exemple de jalonnement avec 3 commandes :

- Article C de la commande 1, pas de nomenclature de fabrication.
- Article A de la commande 2, avec une nomenclature de fabrication.
- Article D de la commande 3, avec une nomenclature de fabrication.

3 : Un algorithme détecte le besoin brut article le plus urgent en multiniveau (date de besoin / priorité de la ligne de commande) ne possédant pas de contrainte (pas d’article père ou article père pour la ligne de commande déjà traité).
- Pour cet article, existe-t-il un besoin plus urgent lié à un père non traité ?
  - Si oui, positionnement sur cet article, existe t'il un même besoin plus urgent - Traitement récursif.

- - Si non, traitement de l’article (idem couverture standard), positionnement du besoin brut.
    - Si aucun besoin n’est nécessaire pour ce nœud de nomenclature alors, le traitement solde tous ces fils.

La fin de la récursivité sur un article ramène le traitement au point 3, un nouvel article prioritaire est déterminé, il est traité de la même façon.

Les priorités définies sont stockées à chaque positionnement traité par l’algorithme dans la table du CBB.

L'article C de la commande 1 est aussi un élément :

- De la nomenclature de l'article A de la commande 2, sa date de besoin phase est positionnée dans le jalonnement avant celui de la commande 1. Le besoin de l'article C pour l'article A de la commande 2 est donc prioritaire sur celui de la commande 1.

- De la nomenclature de l'article D de la commande 3, sa date de besoin phase est positionnée dans le jalonnement avant les deux besoins précédents. Dans ce cas, ce besoin devient prioritaire.

Dans l'exemple, examinons les besoins de l'article C, à quel besoin affecter en priorité le stock disponible de l'article C ?
Question 1 : Quel est l'article des commandes sans contrainte le plus urgent ? Article C cd1
Question 2 : Est ce que pour cet article il existe un besoin plus urgent ? OUI : Article C : cde 3
Question 3 : Oui on peut le placer .
On revient à la question 1 :
Question 1 : Quel est l'article des commandes sans contrainte le plus urgent ? Article C cd1
Question 2 : Est ce que pour cet article il existe un besoin plus urgent ? OUI : Article C : cde 2
Question 3 : Oui on peut le placer .
On revient à la question 1 :
Question 1 : Quel est l'article des commandes sans contrainte le plus urgent ? Article C cd1
Question 2 : Est ce que pour cet article il existe un besoin plus urgent ? NON
Question 3 : Oui on peut le placer

/PDP_L : Gestion des articles manquants

Basé sur les résultats de calcul de couverture précédent /COUV_NEW, ce traitement génère les OFs prévisionnels pour couvrir les manquants. Cette tâche remplace la tâche /PDP.

La couverture donne une liste d’articles manquants par besoin client (Référence / Qté / Date de besoin / Commande client), l'horizon de calcul de la couverture n'est pas limité.

Paramètres pris en compte lors du traitement de la liste :

Le traitement considère que les stocks et les encours ont tous été consommés par le calcul de couverture.
- Le calcul commence avec un stock et un encours de production à 0.
- Chaque élément de la liste génèrera un OFs prévisionnel.
Prise en compte de la quantité & Lot éco : Uniquement sur les articles sans nomenclature
- Le delta entre le besoin et le lancement économique génère un encours de production.
- Il sera consommé par les prochains besoins de cette référence.
Quantité maximum de lancement
Gestion des panoplies

Finalité :

Conservation des OFs prévisionnels existants,
Génération des OFs prévisionnels manquants en masse (traitement PL / SQL) de la couverture.,
Dossier technique / Liste des besoins,
Insertion des OFs prévisionnels dans le tableau de couverture,

Non traité par ce traitement :

Pas de constitution de nomenclature d’OFs prévisionnels,
Pas de jalonnements des OFs prévisionnels,
Pas de traitement des besoins des OFs prévisionnels,
Pas de calcul des statuts des OFs prévisionnels,

Performance constatée

14 800 OFs prévisionnels générés en 8 minutes contre 45 minutes dans la version précédente.

/R_OFS : Calage des Ofs fermes par rapport à la couverture

Cette tâche permet de mettre à jour les données qui concernent les OFs fermes. Ce traitement reprend les OFs fermes pour leur donner les positionnements établis par l’analyse de la couverture et le jalonnement.

Les données mises à jour dont :

Priorité de couverture de l’OFs,
- Reprise de celle de l’OF
- 25 => Pas d’affectation faite dans la couverture
  - NB : Les OFs de réappro de stock sont exclus
- 30 => Pas d’affectation faite par la couverture mais
  - OF avec toutes les pièces en litige
  - Les pièces litiges considérées comme mauvaises
- 40 à OFs de réappro de stock sauf si paramétrage de remise en question actif

- Priorité des Frais de la ligne de commande client affecté
Date de début et date de fin couverture,
Ligne de commande client affectées à l’OFs,
- Affectation indirecte via la table OFS_LG_COUV
- L’OF est affecté principalement au stock (ligne 0/0 **)
Nomenclature de couverture des OFs.
- A partir de la nomenclature théorique d’article,
- A partir des affectations des OFs à la même ligne de commande,
- On constitue des nomenclatures d’OF
- Traitement en PL SQL => Optimisation conséquente du calcul
Gestion des sur nomenclature
- Pour chaque lien de nomenclature créé
  - Calcul des besoins net => Nombre de manquant réel pour l’OF père du fils
  - Sérialisation des OFs
  - Affectation des numéros entre père et fils dans la limite des manquants
  - Si plus de manquant suppression des liens

Un jalonnement de tous les OFs fermes non soldés est effectué :

Traitement récursif des phases
- Détermination des phases libres (toutes leurs phases pères sont positionnées)
- Calcul de la date de début en enlevant le cycle
- Calcul de la date de fin en rajoutant les temps phases
Consolidation sur l’OFs
- Date de début : Minimum des dates de début des phases de l’OF
- Date de fin : Maximum des dates de fin des phases de l’OFDate début et date de fin des OFs,

/DERES_PH : Remise en question des besoins en composant / matières

Cette tâche permet d'effectuer un "remplace" des réservations existantes sur stock et encours, elle remplace /DERES et une partie du traitement /ANA_BES concernant la mise à jour des statuts des Ofs.

Suppressions des réservations composants et matières sur les stocks et encours ainsi que les manquants déclarés pour les OFs fermes.
- Pour les articles :
  - Paramètre de suppression des lancements dédiés activé,
  - Suppression des réservations sur stock et encours,
  - Suppression des nomenclature d’OFs,
  - Transformation des OFs en encours de stock,
    - Les affectations effectuées par la couverture pour les articles en commandes clients sont reprises
      - Création des réservations pour le stock article,
      - Affectation des lignes de commande sur les OFs.
- Pour le négoce :
  - Suppression de toutes les affectations existantes sur stock et encours
  - Suppression de tous les manquants
Constitution d'une liste à traiter :
- Pour chaque OFs non soldés et chaque besoin non soldé de l’OFs :
  - Calcul du reste à sortir pour l’OFs à la date du lien phase du besoin,
  - Priorité (>= 50 sont ramenés à 50),
  - Date de besoin de la phase de l’OF.
- Pour tout le carnet de commande de négoce
  - En fonction du reste à livrer
  - Priorité est figé à 50
  - La date de livraison ou date recalée détermine la date de besoin
- Les besoins sont triés par :
  - Priorité
  - Date de besoin
Parcours de la liste
- Pour chaque élément, affectation du stock principal de l’élément
  - Si pas suffisant, affectation du stock de consignation de l’élément,
  - Si pas suffisant, affectation du stock des liens équivalents,
  - Si pas suffisant, affectation de l’encours de commande d’achat de l’élément.
  - Si pas suffisant, affectation de l’encours de commande d’achat des liens équivalents
  - Si pas suffisant alors un manquant est déclaré sur le besoin principal

A la fin du traitement :
- Calcul du statut des OFs
- Uniquement pour les OFs en attente ou disponible
  - Passage au statut disponible de tous les OFs ci-dessus
  - Passage au statut en attente
  - Existe une nomenclature d’OF
  - Existe une réservation sur encours de production article pour l’OF
  - Existe une réservation sur un encours de commande d’achat pour l’OF
  - Existe un manquant déclaré pour l’OF

/R_OFS_PREV : Calage des Ofs prévisionnels par rapport à la couverture

Cette tâche permet de mettre à jour les données qui concernent les OFs prévisionnels. Ce traitement reprend les OFs previsionnels pour leur donner les positionnements établis par l’analyse de la couverture.

Les données ci-dessous sont mises à jour sur les OFs prévisionnels
- Priorité de couverture :
  - Reprise de celle de l’OF prévisionnels,
  - 45 à Pas d’affectation faite dans la couverture :
    - Par exemple : horizon de calcul de la couverture n’englobe pas tout le carnet de commande client
- Ligne de commande client affectées à l’OFs :
  - Affectation directe dans la table PDP_OFS_LG,
  - L’OF prévisionnel non pris en compte par la couverture n’est pas remis en question. Il conserve les lignes de commandes clients d’origine.
- Nomenclature d’OFs prévisionnels :
  - Le processus de calcul est le même que pour les OFs fermes,
  - L’algorithme de gestion des sur nomenclature s’applique aussi.
Un jalonnement de tous les OFs prévisionnels est effectué :
- Même méthodologie que pour les OFs fermes,
- MAJ des cycles des phases fermes et prévisionnelles,
- Constitution des nomenclatures de phases prévisionnelles,
- Constitution des nomenclatures mixte entre phases fermes et phases prévisionnelles,
- Par rapport au référentiel (Couverture / Axone PDP ) mise à jour des phases libres (sans contrainte de nomenclature de phase supérieure) : date de début et date de fin,
- Traitement récursif qui parcourt l’ensemble des nomenclatures de phases pour les jalonner,
- A la fin du balayage mise à jour des dates de début et date de fin des OFs prévisionnels,
Le référentiel des OFs fermes a changé.
- Le calcul pour les OFs fermes est refait :
  - Prise en compte du référentiel pour mettre à jour les phases fermes libres,
  - Balayage de la nomenclature de phase pour rejalonner les phases,
  - Mise à jour des l’OFs.

/DERES_PDP : Remise en question des besoins en composant / matières

Cette tâche permet d'effectuer un "annule et remplace" des réservations existantes sur les Ofs prévisionnels :

Suppression des réservations composants et matières sur les stocks et encours ainsi que les manquants déclarés sur les OFs prévisionnels,
Les besoins articles ne sont pas remis en cause,
Les commande de négoce ne sont pas prise en compte,
Pour chaque OFs prévisionnels et chaque besoin de l’OFs.
- Calcul de la quantité nécessaire pour l’OFs à la date du lien phase du besoin.
- Les besoins sont triés par :
  - Priorité (>= 50),
  - Date de besoin,
  - OFs.
- Le stock est affecté (principal puis équivalent) puis l’encours. Si le besoin n’est pas couvert un manquant est déclaré sur le besoin principal.