...

• 2. Gestion de la mémoire : Passage en 64 bits
  • Optimisation des traitements en mémoire et 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 ont constatées constatent des crashs aléatoires des dll, la mise en place de la version 64 bits a permis permet d'éradiquer ces instabilités liées aux limites 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 priorité les besoins Articles issu issus du carnet de commande client. C'est le calcul des besoins bruts (CBB) jalonné en multi niveaux qui permet de prioriser les affectations . le traitement parcourt les besoins bruts multi niveaux de chaque article pour prioriser les besoins en fonction des dates de besoins des phases et celles du carnet de commande, si un besoin article non couvert est avéré sur une phase, alors si sa date de besoin intervient avant celle d'une commande, alors c'est le besoin de la phase qui est prioritaire pour l'affectationliées au carnet de commandes client. Si un article doit être consommé sur une phase de nomenclature d'un article père alors l'affectation du stock à ce besoin est prioritaire s'il est avéré et s'il précède un besoin en commande client.
  • Les rechanges sont maintenant gérées dans le traitement de la couverture.
  • Les indices articles sont maintenant 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 =>Les différents tableaux de bords présentent tous des données cohérentes. Les calculs de dates de disponibilité sont cohérentes dans les différents rapportsles 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 aussi en versions 32 bits.

La mise en place de ces nouvelles tâches nécessitera de vous faire accompagner par nécessite un accompagnement avec vos intervenants habituels Helios ERP . C'est importants de respecter la séquence décrite pour profiter des optimisationspour éviter des redondances dans les traitements ou le lancement de traitements inutiles dans le contexte de votre process de production.

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

...

• 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émoiremé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. Détail des nouvelles tâches 2.0.

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

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

...

Ce traitement génère les OFs du plan de production Axone.

...

Il  remet en question les OFs prévisionnels existants, il les supprime tous et 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 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) 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é, l'affectation peut se faire sur un article à consommer dans une nomenclature d'un article père ou sur un article du carnet de commande suivant la date de besoin la plus prioritaire.

Elle apporte des gains fonctionnels notables, notamment la prise en compte des indices articles et , 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 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é
    est conservé car un lien fort existe avec
    • à la ligne de
    commande
    • la commande est conservé.
  • Sinon 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 .Pas de prise en compte des encours de fabricationni 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

Exemple de jalonnement avec 3 commandes :

...

Pour chaque besoin identifié comme plus urgent et par priorité croissante, le traitement analyse si le besoin est avéré en remontant les niveaux de la nomenclature concernée. Si le besoin n'est pas avéré, dans le cas où le père de plus haut niveau est en stock, par exemple, la nomenclature peut être supprimée. Le traitement est récursif. 

Les dates de lancement sont calculées des OFs sont mises à jours à la fin du traitement. 

2.3. /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. Des Of prévisionnels sont créés pour couvrir les trous, un par trou.

...

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

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

...

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

...

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.

...

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

2.7. /DERES_PDP :

...

Remise en question des besoins en composant / matières

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

...

• 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.4pour éviter la redondance de traitements inutiles.

...