Sommaire :

1. Introduction

Les tâches concernées par l'évolution 2.0 sont les 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 un planificateur de tâches. 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 tout en optimisant vos coûts de production. 

Prérequis : l’option « Jalonnement à la phase » doit être activée pour utiliser ces nouvelles tâches

Ces traitements exécutaient tout ou partie des tâches suivantes dans l'ordre indiqué dans la version 2.4 (En vert , les taches non concernées par ce projet 2.0) :

1. /PROG_PROD : Programme de production Helios.
2. /COUV : Calcul de la couverture,
3. /R_OFS : Retour couverture vers les OFs,
4. /DERES_PH : Dé réservation des OFS,
5. /PDP : Calcul des Besoins Nets Prévisionnel,

6. /ANA_BES: Analyse des besoins des OFs,

7. /COUV : Calcul de couverture,
8. /R_OFS : Retour OFs,
9. /R_OFS_PREV Retour sur les OFs prévisionnels,
10. /BASOR : Calcul des ouvertures et calendriers des ressources, 
11. /PLANIF : Ordonnancement à capacité finie et infinie, 
12. /CBA : Calcul des besoins achats.
13. /BILAN : Calcul des bilans,

Un soin particulier de refonte a été apporté par l'équipe Hélios ERP sur certaines de ces tâches, il porte sur les points d'amélioration et d'optimisation suivants :

• 1. Les Temps d'exécution des tâches  :
  • Passage en PL SQL de certains algorithmes pour bénéficier des gains de performance des traitements en masse. Suppression des algorithmes pas a pas  (/R_OFS et /R_OFS_PREV).
  • Optimisation des algorithmes de traitement.
  • Suppression des traitements redondants (/COUV),
  • Suppression de l'utilisation des IHM dans les traitements (/PDP, /DERES),

Les gains sont significatifs : 

• • • Gains supérieurs à 40 %, sur les temps de traitement, variables selon les caractéristiques du serveur et le volume des données.

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

• • • Pour les sociétés qui manipulent un volume de données important et qui constatent des crashs aléatoires des dll, la mise en place de la version 64 bits des traitements permet d'éradiquer ces instabilités liées aux limites de l'architecture de Windows 32 bits.

• 3 . Amélioration de la couverture fonctionnelle :
  
  • La priorité d’affectation des stocks et encours dans la couverture ne priorise plus en premier les besoins Articles issus du carnet de commande client. C'est maintenant le calcul des besoins bruts (CBB) jalonné en multi niveaux qui permet de prioriser les affectations. Si un article doit être consommé sur une phase de nomenclature d'un article père alors la priorité d'affectation est ce besoin s'il précède un besoin en commande client.
  • Les rechanges sont gérées dans le traitement de la couverture.
  • Les indices articles sont gérés 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 différents tableaux de bords présentent des données cohérentes. Les dates de disponibilité sont les mêmes d'un rapport à l'autre.
  • Prise en compte du négoce dans l'ensemble des tâches y compris les taches de dé réservation.
  • La dé réservation inclut les OFs prévisionnels.

Il en résulte la livraison de nouvelles tâches optimisées en version 64 bits et 32 bits. Certains d'entre vous ont déjà bénéficié de l'optimisation de certaines de ces tâches dans le cadre du processus de mise à jour continue de la version 2.4 Evol de Hélios ERP.

La mise en place de ces nouvelles tâches nécessite cependant, un accompagnement avec vos intervenants habituels Helios ERP pour optimiser votre process avec l'apport de ces améliorations et éviter le lancement de traitements redondants ou inutiles.

Scénario complet, la séquence est la suivante :

1. (/PDP /OFS : Génération des OFs fermes à partir du CBN prévisionnel planifié et types de gamme codifiées)
2. /PDP : Plan de production minimaliste (Paramètre Plan de production), intègre le programme Helios PDP.
3. /COUV_NEW ou /COUV_NEW_FULL : Couverture article, remplace /COUV.
4. /PDP_L : Génération des OFs prévisionnels manquants,
5. /R_OFS : Retour OFs, mise à jour des OF Fermes,  passage en PL SQL.
6. /DERES_PH : Dé réservation OFS, remplace /DERES et une partie du traitement /ANA_BES qui n'existe plus.
7. /R_OFS_PREV : Retour sur les OFs prévisionnels, passage en PL SQL.
8. /DERES_PDP : Dé réservation OFS prévisionnels, Elle optimise les achats prévisionnels, 
9. /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.
10. /GMAO : Calcule du planning de maintenance des moyens
11. /BASOR : Calcul des ouvertures et calendriers des ressources.
12. /PLANIF : Ordonnancement à capacité finie et infinie.
13. /CBA : Calcul des besoins achats.
14. /BILAN : Calcul des bilans.
15. /CYCLAR : mise à jour des moyennes de cycle gamme 
16. (/MRP : mise à jour des données PDP et PIC) 

Scénario minimum, la séquence est la suivante :

1. (/PDP /OFS : Génération des OFs fermes à partir du CBN prévisionnel planifié et types de gamme codifiées)
2. (/PROG_PROD : Génération des OFs fermes et prévisionnels à partir du programme de production)
3. /COUV_NEW ou /COUV_NEW_FULL  : Affectation théorique des stocks et encours : Favorise le besoin le plus urgent. Détection des manquants de production
4. /PDP_L : Génération des OFs prévisionnels pour combler les manquants
5. /R_OFS : Lier l’OFs ferme aux besoins initiaux et le jalonner
6. /DERES_PH
7. /R_OFS_PREV : Lier l’OFs prévisionnel aux besoins initiaux et le jalonner
8. /DERES_PDP
9. /R_COUV : Calcul des dates de disponibilité et consolidation des tableaux de bord
10. /GMAO : Calcule du planning de maintenance des moyens
11. /BASOR : Plage d’ouverture par jour des moyens
12. /PLANIF : Planification capacité infinie et finie des OFs ferme et prévisionnels. Plan de charge / planning au poste / Date planifiée / Délai prévisionnel de livraison
13. /CBA : Consolidation & génération du prévisionnel d’achat
14. /BILAN
15. /CYCLAR : mise à jour des moyennes de cycle gamme 
16. (/MRP : mise à jour des données PDP et PIC)

Pour exécuter les nouvelles 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 Windows 64 bits).
• 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 compatible 64 bits de votre environnement qui exécute les tâches.

2. Les tâches 2.0 à utiliser dans les traitements planifiés

2.1. /PDP  : PDP minimaliste - Intégration du plan de production Helios avec RAZ du prévisionnel.

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

Ce traitement remet en question les OFs prévisionnels existants, il les supprime tous.

Puis il génère les OFs fermes et prévisionnels du plan de production Helios.

Et enfin, il regénère les Ofs prévisionnels selon le carnet de commande en place.

Utiliser ce traitement si un RAZ du prévisionnel est nécessaire sinon utiliser la tâche /PROG_PROD*.

Ce traitement ne gère pas la nomenclature des Ofs prévisionnels, à ce stade :

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

2.2. /COUV_NEW : Analyse de la couverture, le cœur 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) jalonné en multi niveaux pour prioriser les besoins articles à sortir. Elle permet de donner au plus prioritaire des besoins d'abord le stock puis l'encours le plus avancé. Le plus prioritaire peut être un besoin article à consommer dans la nomenclature d'un article commandé, Il n'est plus forcément un article commandé.

L'encours est représenté par tous les OF non soldées et non suspendus plus les of de retouche (OF de retouche liée a une décision stock purge, marquage et montage sont envoyé dans la couverture)

La priorisation du carnet de commande devient secondaire, elle est prise en compte uniquement si un même article à une même date de besoins pour n lignes de commande.

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

A la fin du calcul, la couverture est connue. Les dates des Ofs sont mises à jours.

Exemple de log généré :

Principe du traitement :

Pour chaque besoin Article du carnet de commande, reconstruction et jalonnement de la nomenclature multi niveaux de chaque article, calcul des besoins bruts de chaque niveau de nomenclature :

• 1 : Initialisation des nomenclatures du carnet de commande client => Duplication des nomenclatures sur les lignes de commande.
  • Si un verrou existe, lien fort entre la ligne de commande et un OF, alors ce verrou est conservé.
    • => Le dossier technique de l’OFs dédié à la ligne de la commande est conservé.
  • Si aucun verrou n'existe, le dossier technique standard de l'article est repris pour constituer la nomenclature.

• 2 : Décomposition du carnet de commande en besoins bruts articles (Calcul des Besoins Bruts ou CBB), sur tous les niveaux de nomenclature des articles du carnet de commande. Il permet notamment  de calculer les données nécessaires à la gestion Kanban 
  • => Pas de prise en compte ni des stocks ni des encours, c'est le principe du CBB.
• 3 : 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 et délais de sécurité.

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 qui consomme C.
  • Article D de la commande  3, avec une nomenclature de fabrication qui consomme C.

• 4 : Placement des affectations des stocks et des encours via un exemple :

Le chemin vert du schéma : Parcourt de placement de la première affectation

• • Un algorithme parcourt les éléments du carnet de commande. Il identifie l'article du carnet de commande non affecté le plus urgent sans père, dans l'exemple, l'Article C : Cde1 (1 vert), ce traitement teste s'il existe une nomenclature créée dans l'étape 1 d'initialisation des nomenclatures qui consomme aussi l'article C avec un besoin plus urgent.
    • Si aucune consommation n'est plus urgente, l'affectation est opérée directement pour servir la commande (1 vert), et le traitement passe à l'article suivant du carnet de commande.
    • Si une première consommation de l'article doit avoir lieue avant, c'est le cas de la nomenclature de l'article D : cde3 (2 vert) alors le traitement se positionne sur ce niveau de nomenclature.

• • Pour ce besoin identifié comme le plus urgent : Le traitement analyse si l'affectation peut se faire directement sur le besoin C : cde3 (2 vert), la réponse est NON, car le besoin est lié à un père (Article B : cde 3) non affecté.

Le traitement remonte donc les niveaux de la nomenclature pour détecter s'il existe ou non un besoin plus urgent pour les différents éléments de la nomenclature, c'est le cas pour l'article F : cde3 (5 vert) qui est aussi un élément de la nomenclature de l'article A : cde2 qui est pus urgent (6 vert).

Ce dernier besoin devient prioritaire. le traitement remonte les niveaux de cette autre nomenclature à partir du niveau où il se trouve de la même façon que précédemment pour arriver sur l'article A : cde 2 libre de contrainte (7 vert) (pas de consommations plus urgente dans les nomenclatures).

La première affectation est donc l'article A qui se voit affecter le stock disponible A pour couvrir la totalité ou une partie du besoin sinon ou en supplément les encours de A pour couvrir la totalité ou le reliquat. Si le besoin n'est pas couvert totalement, un manque est déclaré. Le numéro rouge représente le numéro d'affectation de la priorité 1 dans notre exemple.

Le chemin rouge du schéma : Chemin parcouru après l'affectation du besoin de la commande 2

Ensuite le traitement revient en arrière d'une position, peut on placer le besoin F : cde 2 ?, c'est le chemin rouge.

La réponse est OUI, il n'a pas de père non placé, il n'a pas non plus de besoins plus urgents, il adopte le numéro 2 (rouge) dans l'ordre des affectations.

Le traitement, redescend d'une position, Le besoin F : cde3, peut il être placé ?, La réponse est NON car il a un père, l'article D : cde3. Ce dernier est libre de contrainte il adopte la position 3 (rouge) dans l'affectation.

Le chemin bleu du schéma : Chemin parcouru après l'affectation du besoin de la commande 3

Ensuite le traitement revient en arriéré d'une position, le besoin F : cde3, son père est placé, il n'y a aucun autre besoin prioritaire, son affectation est possible en position 4 (rouge).

Et ainsi de suite pour tous les articles du carnet de commande.

A la fin du traitement, une liste permet de dresser la couverture des besoins du carnet de commande via le stock et les encours, les quantités d'affectation de chaque ligne de commandes par le stock et/ou les numéros d'OFs et/ou les numéros d'Ofs prévisionnels et ou les manquants à produire par besoin client (Référence / Qté / Date de besoin / Commande client). L'horizon de calcul de la couverture n'est pas limité.

2.2.1 OF de retouche avec nomenclature article-article

[DEB 2023Q4.240219]

Prise en compte des lignes de commandes de type Non Qualité Interne dans le référentiel (Positionner sur les commande de stock ("Année"/0)) Une ligne pour chaque OF de retouche ayant au moins un besoin article lié a une NC non soldée.

• Calcul des besoins brut des ligne de type Non Qualité Interne
• Jalonnement et priorisation des besoins de ces lignes
• Traitement par le standard de ces nouveaux besoins
  • Particularité : l'OF de retouche sera attribué au besoin de la ligne de commande client de type NC interne → Pas de remise en cause de ce lien 

NB : ces types de lignes Non Qualité Interne sont créés automatiquement lorsqu'on ajoute un besoin article dans un OF de Remise en conformité (créé par une NC, décision remise en conformité)

Extrait du log de la couverture

[FIN 2023Q4.240219]

[DEB 2024Q4.240825]

2.2.2 /COUV_NEW_FULL

A utiliser que le week-end chez les clients ayant un fort volume de données à traiter et qui sont dans l'obligation de brider le calcul via le paramètre Horizon de calcul couv dans le paramétrage Analyse de la couverture  .

[FIN 2024Q4.240825]

2.3. /PDP_L : Génération des Ofs prévisionnels 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.

Des Ofs prévisionnels sont créés pour couvrir les trous de la couverture, un Ofs prévisionnel par trou. L'horizon de couverture n'est pas limité, plus il est grand, meilleur est la couverture.

Paramètres pris en compte lors du traitement de génération de la liste des manquants :

• Le traitement considère que les stocks et les encours ont tous été consommés par le calcul de la couverture. Le traitement /COUV_NEW précédent est donc une étape préalable indispensable.
  • Le calcul considère donc les stock et les encours de production comme s'ils n'existaient pas.
  • Chaque élément de la liste des manquants générée par la couverture génèrera un OFs prévisionnel (matérialisé en rouge ci-dessous), c'est un traitement PL SQL en masse, il Insert les nouveaux OFs prévisionnels dans le tableau de la couverture.

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

A ce stade :

Les Ofs prévisionnels sont posés aux dates de besoins.

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

Exemple de Log :

2.4. /R_OFS : Jalonnement des Ofs fermes par rapport à la couverture

A ce stade, le carnet de commande a des affectations de stock ou d'encours pour tous les besoins. 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, OFS non liés à un besoin de 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, uniquement si paramétrage décoché "considérer les pièces litigieuses comme bonnes"
  • 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é.
• 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
  • Un OF peut être affecté à plusieurs lignes de commande ou inversement
  • Les quantités de production diffèrent des quantités commandées
  • Des besoins sont couverts par le stock
  • Trop de lien entre OFs sont créés
    • Les dates de contraintes des nomenclatures positionnent les OFs trop tôt.
• 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.

           Extrait d'un Log :

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

• Jalonnement des OFs

• • Cas : Jalonnement à la phase => Plus pertinent et performant
    • Soit avec l'option "Coller à la gamme",
    • Soit via les cycles inter CDC,
    • Soit via les temps d’attente entre 2 CDC ,
      • Cycle : Quantité OFs et temps phase + temps d’attente ou délai de ST
  • Positionnement du cycle sur les phases d’OFs
  • Constitution de nomenclature de phase d’OFs
    • A partir des nomenclatures de couverture et du déroulé opératoire
    • Chevauchement de nomenclature d’OFs
  • Détermination des phases libres (pas de contraintes de nomenclature)
  • Calcul de la date de fin des phases libres en fonction du référentiel (Couverture / Helios PDP / OFs prévisionnel) et du délai de sécurité
  • Calcul de leurs dates de début (fonction du temps phase)

• 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’OF.

2.5. /DERES_PH : Déréservation des Ofs fermes => Remise en question des besoins en composant / matières des OFs fermes

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.

• 1 . 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
• 2. 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 les composants
      • Recalcule du besoins dans l'unité du besoin défini sur l'of et non en unité international
  • 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
• 3. 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.

• 4. 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.

2.6. /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.
  • Création des 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é :

Exemple de log :

• • 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 / Helios 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.

2.7. /DERES_PDP : Remise en question des besoins en composant / matières des OFs prévisionnels

Cette tâche permet d'effectuer un "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,
• Prendre en compte les commandes de négoce dans le processus
• 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.
    • Pour les composants
      • Recalcule du besoins dans l'unité du besoin défini sur l'of et non en unité international
  • 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.

Performance constatée

• Sur un échantillons de 19 000 éléments à traiter le temps de traitement est passé de 11 h à 4h15.

2.8. /R_COUV : Insertion des données liées aux composants et matières dans les tableaux de couverture

Cette tâche permet de mettre à jour la couverture des commandes clients avec mise à jour des dates de disponibilité des composants et matières. Elle évite la réexécution de la tâche /COUV de la version 2.4 pour éviter la redondance de traitements inutiles.

1. Chargement de la couverture réelle des besoins de chaque OFs ferme et prévisionnels
   • Pour chaque composant et matière, établissement des données suivantes  :
     • Besoin théorique,
     • Quantité sortie (lien principal et lien équivalent),
     • Quantité substituée,
     • Quantité réservée en stock,
     • Quantité réservée sur les commandes d’achat et détail des positionnements.

Exemple de log :

• 2. Parcours des nomenclatures théorique des lignes de commande client par priorité du CBB
  • Pour un couple article / composant (ou matière) on connait la liste des OFs (ferme ou prévisionnel) qui couvre l’article et le nombre de pièce de l’OF utilisé
  • A partir des informations remontées précédemment on affecte jusqu’à atteindre le besoin théorique, par ordre de priorité
    • Le besoin théorique (si le composant n’est pas présent dans la liste des besoins de l’OFs alors besoin théorique sera égal à 0),
    • Les quantités sorties (sur lien principal puis sur lien équivalents),
    • Les quantités substituées (sur lien principal puis sur lien équivalents),
    • Les réservations sur stock (sur lien principal puis sur lien équivalents),
    • Les réservations sur encours (sur lien principal puis sur lien équivalents).
  • Mise à jour des dates de disponibilité dans la couverture
    • Pour chaque besoin dans la couverture possédant une réservation sur un encours d’achat
    • Création des liens vers la ligne de commande fournisseurs dans la table C_CMD_LG_COUV_DET
    • Mise à jour de la date de disponibilité pour le besoin de couverture en fonction des informations de la ligne de commande fournisseur (date recalée ou date de livraison)
    • Mise à jour de la date de disponibilité du besoin dans le cas d’un manquant via les conditions d’approvisionnement du fournisseur prioritaire
  • Mise à jour des dates de disponibilité pour les articles couvert par des OFs ferme ou prévisionnels
    • Date de fin planifiée ou date de fin de charge ou date de fin de couverture.
  • Mise à jour des dates de disponibilité sur les OFs
    • Descente des dates de disponibilité de la couverture vers les OFs
      • Liste des besoins
      • Lien phase d’OFs avec besoin
      • Phase d’OFs
    • Remontée des données de disponibilité dans les tables de planification