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 leun 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 tout en optimisant vos coûts de production. 

• Traitement des besoins bruts.
• Jalonnement des besoins bruts.
• Conversion en besoins nets.
• Génération des Ofs prévisionnels
• Mise à jour des encours et des réservations.
• Besoins en achats...

...

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 traitements suivants 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 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,

...

1.  
2. /PLANIF : Ordonnancement à capacité finie et infinie, 
3. /CBA : Calcul des besoins achats.
4. /BILAN : Calcul des bilans,

Un soin particulier de refonte a été apporté par l'équipe HéliosERP pour déterminer les optimisations possibles et les améliorations à apporter pour une meilleure couverture fonctionnelle.Plusieurs axes ont été traités 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
(/PDP)
• • .
Regroupement de certains traitements et suppression
• • Suppression des traitements redondants (/COUV),
  • Suppression de l'utilisation des IHM dans les traitements (/PDP, /DERES
, /PDP
• • ),
• Suppression des algorithmes pas a pas dans les traitements (/R_OFS et /R_OFS_PREV).
2. L'espace mémoire alloué aux traitements 32 bits par Windows :

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
et
• • avec le passage en 64 bits des traitements pour permettre d'allouer plus de 2 Go d'espace
mémoire aux traitements
• • mémoire  (Voir : Limites de mémoire pour les versions de Windows et de Windows Server - Win32 apps | Microsoft Learn). 
• 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 (/COUV) et de planifications (/PLANIF).

• 3. La stabilité des traitements et la reprise des traitements en cas d'erreur,
  • Crash aléatoire des dll => Libération de la mémoire défaillante.
  • Difficulté pour établir une procédure minimale de tâches à exécuter lors de la mise en place.

4 . La couverture fonctionnelle, prise en compte des fonctionnalités non couvertes :
Prise en compte des indices articles
• • • 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.Prise en compte des rechanges
  • Les indices articles sont gérés dans le traitement de la couverture.
  • Prise en compte de la gestion Gestion des approvisionnements partiels dans la mise à jour de la couverture,Prise en compte de la gestion .
  • Gestion des stocks par emplacement dans la mise à jour de la couverture,
  • Calcul des dates de disponibilité dans la mise à jour de la couverture.
  • Prise en compte de la priorité d’affectation des stocks et encours dans la couverture en fonction des dates de besoins, le besoin d'un composant de nomenclature peut être prioritaire sur un besoin de commande client.
  • 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 qui annulent et remplacent les tâches que vous connaissez. en bleu noire dans la liste des traitements présent dans le scénario minimum. Les tâches en vert n'ont pas été impactées par les évolutions.

...

/COUV_NEW : Couverture article, remplace /COUV.

...

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

...

/CBA : Calcul des besoins achats. 

Les gains constatés en temps d'exécution sur nos environnements de tests sont très significatifs, chez nos sites pilotes, on se situe entre 45 et 50% de gain.

...

Remarque :

La tâche ANA_BES n'est plus utilisée car les traitements sont réalisés par d'autres tâches

• Les statuts d’OFs sont gérés par la tâche /DERES_PH,
• Les dates de disponibilités des phases sont gérées par la tache /R_COUV,
• Les statuts de besoin des phases sont gérés par la tache /R_COUV.

Les tâches suivantes ne sont pas impactées :

• /BASOR
• /PLANIF
• /BILAN

2.Détail des tâches 2.0.

/COUV_NEW

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 prend en compte non seulement des besoins issus du carnet de commandes clients mais aussi des besoins en nomenclature des articles commandés 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) :

• 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.
  • Dépend du paramétrage
    • Cycle à la phase
      • Temps d’attente des CDC
      • Cycle inter CDC
    • Cycle Gamme
    • Temps de la Gamme

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.

Image Removed

• 3 : Un  algorithme détecte le besoin brut article le plus urgent en multiniveau (date de besoin / priorité de la ligne de commande) libre de contrainte (pas d’article père ou article père pour la ligne de commande déjà traité).
  • Pour chaque article d'une commande, existe-t-il un besoin plus urgent lié à un père non traité ?
    • Si oui, positionnement sur cet article en commande, 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.

Dans l'exemple, examinons le besoin de l'article C, la numérotation désigne les priorités de prise en compte des besoins par le traitement.Image Removed

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 à la même date que celle de la commande 1. Dans ce cas le besoin de la commande 1 est prioritaire, puis vient ensuite celui de la commande 3.

• 4 : Le stock, l’encours de prod ferme ou prévisionnel est associé aux différents besoins pour convertir les besoins bruts en besoins nets (CBN).

En fonction de l’affectation réalisée le besoin brut fils est remis en question pour chaque article concerné, cette procédure récursive se déroule jusqu’à avoir traité tous les besoins bruts articles détectés par le CBB, les besoins brut des articles deviennent des besoins nets.

• 5 : A ce stade, les besoins bruts en composant et en matière ne sont pas traités.
• 6 : Les dates de lancement sont calculées à la fin du traitement.

/PDP /COUV

Basé sur les résultats de calcul de couverture précédent /COUV_NEW (CBN), ce traitement génère les OFs prévisionnels pour couvrir les besoins net a fabriquer. Cette tâche remplace la tâche /PDP (32 bits).

• Chaque besoin net de fabrication est traité.
• Un OFs prévisionnel est généré pour chacun des besoins nets non couverts.
  • A ce stade, la nomenclature d’article n’est pas encore prise en compte, les besoins en composants et matières ne sont pas traités.
  • Les quantités et lots économiques sont pris en compte (Si un encours de production est généré via un lot économique par exemple il sera pris en compte avant génération éventuelle de l’OFs).
• Les données calculées par la couverture sont ensuite mises à jour avec les données des OFs prévisionnels générés.

/R_OFS

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.

Ces données sont  :

• Priorité de l’OFs,
• Date de début et date de fin couverture,
• Ligne de commande client affectées à l’OFs,
• Nomenclature de couverture des OFs.

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

• Date début et date de fin des OFs,
• Date de début et date de fin des phases,
• Date des réservations stock et encours pour les composants et matières,
• Date des manquants pour les composants et matières.

/DERES_PH

Cette tâche permet d'effectuer un "annule et remplace" des réservations existantes sur stock et encours, elle remplace /DERES et une partie du traitement /ANA_BES (32 bits) 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
  • 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 et créées sur le stock article et sur les encours de production
• 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,
  • 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.
  • Dé réservation à la phase  : suppression des réservations des commandes de négoce sur stock, encours et manquant et prise en compte des lignes de commande clients de négoce au statut encours dans le processus de dé réservation. Les besoins de négoce sont pris en compte à la date recalée ou de livraison de la ligne. Ils s’insèrent au milieu des besoins des phases d’OFs.

/R_OFS_PREV

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 l’OFs,
  • Date de début et date de fin couverture,
  • Ligne de commande client affectées à l’OFs,
  • Nomenclature de couverture des OFs.
• Un jalonnement de tous les OFs prévisionnels est effectué :
  • Date début et date de fin des OFs
  • Date de début et date de fin des phases
  • Date des réservations stock et encours pour les composants et matières
  • Date des manquants pour les composants et matières

/DERES_PDP

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

• Suppression des OFs prévisionnels non liés à la couverture ou au Plan de production (priorité 95),
• 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,
• 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.

/R_COUV

...

/CBA

Cette tâche permet d'effectuer le calcul des besoins achat.

3. Rappel des paramètres pris en comptes dans les tritements

Tous les paramètres de gestion pris en compte dans les anciennes tâches sont également pris en compte.

Analyse de la couverture

Image Removed

Les Besoins :

Image Removed

Paramétrage Plan de production

Image Removed

OF

Image Removed

Paramétrage de Gestion des cycles

Image Removed 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.

Image Added