Sommaire

1. Introduction

Hélios ERP met à votre disposition une bibliothèque de tâches que vous pouvez automatiser. Il s'agit de tâches exécutables en ligne de commande.

Ces tâches dépendent des droits d'accès aux fonctionnalités concernées et aux paramètres de gestion définis dans les paramétrages de Hélios ERP.

Beaucoup de fonctionnalités sont concernées :

Les traitements de Hélios ERP,
Crystal Report,
Hel_FAV et les requêtes pour le pilotage d’atelier et les consultations de plans,
L’EDI et ses différents traducteurs,
Les transferts en comptabilité,

Il est possible de placer ces raccourcis sous la forme de lignes de commande dans un fichier ".CMD".

Le raccourci doit pointer sur l'exécutable HeliosII.exe pour les traitements exécutables en 32 bits ou sur l'exécutable HII_TASKx64.exe pour les traitements exécutables en 64 bits. Le traitement à exécuter est un code tâche à passer en paramètre à l'exécutable.

Exemples :

...HeliosII.exe /PDP

...HII_TASKx64.exe /PDP

Il est possible de passer en paramètre un fichier "ini" de connexion au profil de la base de données avec les identifiants de connexion d'un utilisateur habilité a exécuter les traitements. Ce fichier doit être présent dans le même répertoire que l'exécutable.

Exemples :

...HeliosII.exe HeliosII_XXXX.ini /PDP

...HII_TASKx64.exe HII_TASKx64_XXXX.ini /PDP

ou

...HeliosII.exe /PDP HeliosII_XXXX.ini

...HII_TASKx64.exe /PDP HII_TASKx64_XXXX.ini

il s'agit d'une copie du fichier de connexion HeliosII.ini pour les tâches en 32 bits.

; Fichier HeliosII.ini
[HeliosII]
LANGUE=FR
ORGANISATION=CLIP INDUSTRIE
IDENTIFICATION=ERP, HéliosII
BASE=O10
USER=ADMIN
PASS=
USERCODE=1
BGInfo=O
UTIL_IMP_DEFAUT=1
CCleaner=N

[REPERTOIRE]
ARCHIVE=C:\data\HeliosII\Archive\V2.4.00\

EDI=J:\EDI\

[Window]
ChargeXY=0

ou d'une copie du fichier de connexion HII_TASKx64 pour les tâches en 64 bits.

; Fichier HeliosII.ini
[HII_TASKx64]
LANGUE=FR
ORGANISATION=HELIOS ERP
IDENTIFICATION=ERP, HéliosII
BASE=O10
USER=ADMIN
PASS=
USERCODE=0
BGInfo=N
CCleaner=N
UTIL_IMP_DEFAUT=1

[REPERTOIRE]
ARCHIVE=C:\data\HeliosII\ARCHIVE\V2.4.00

EDI=J:\EDI\

[Window]
ChargeXY=0
[HII_TASK]
BGInfo=O

Remarque :

Si plusieurs bases de données sont présentes dans le fichier ini, seule la première base de données est prise en compte.

2. Les codes tâches pour la gestion du moteur ORACLE

/EXPORT : Pour l’export light des données dans c:\heliosii\log\ du poste.
/SESSION : Pour historiser les sessions Oracle actives et surveiller les inter blocages.
/ORA : Pour gérer en visuel ces sessions Oracle.

3. Les codes tâches pour la réorganisation de la production

Il s'agit des tâches que vous pouvez lancer touts les soirs et/ou tous les Week-end, c'est pourquoi nous avons prix l'habitude de communiquer sur ces tâches en les qualifiant de "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. Elles assurent la cohérence entre le carnet de commande, la production et les achats.

Ces traitements permettent de gérer correctement le cadencement des OFs pour faire face aux multiples remises en question du carnet de commande ou des aléas de fabrication. Le replacement des OFs dans le temps entraîne celui des achats et une remise en question de la gestion du stock (réservations Hélios). La solution pour gérer cette problématique dans Hélios ERP consiste à utiliser les lancements de plusieurs tâches planifiées (Optim supply).

La mise en place de ces tâches nécessite un accompagnement avec vos intervenants habituels Helios ERP et l’option « Jalonnement à la phase » doit être activée pour utiliser ces nouvelles tâches

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

SCHEMA DU FLUX

(/PDP /OFS : Génération des OFs fermes à partir du CBN prévisionnel planifié et types de gamme codifiées)
/PDP : Plan de production minimaliste (Paramètre Plan de production), intègre le programme Helios PDP.
/COUV_NEW ou /COUV_NEW_FULL : 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.
/GMAO : Calcule du planning de maintenance des moyens
/BASOR : Calcul des ouvertures et calendriers des ressources.
/PLANIF : Ordonnancement à capacité finie et infinie.
/CBA : Calcul des besoins achats.
/BILAN : Calcul des bilans.
/CYCLAR : mise à jour des moyennes de cycle gamme
(/MRP : mise à jour des données PDP et PIC)

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

(/PDP /OFS : Génération des OFs fermes à partir du CBN prévisionnel planifié et types de gamme codifiées)
(/PROG_PROD : Génération des OFs fermes et prévisionnels à partir du programme de production)
/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
/PDP /L : Génération des OFs prévisionnels pour combler les manquants
/R_OFS : Lier l’OFs ferme aux besoins initiaux et le jalonner
/DERES_PH
/R_OFS_PREV : Lier l’OFs prévisionnel aux besoins initiaux et le jalonner
/DERES_PDP
/R_COUV : Calcul des dates de disponibilité et consolidation des tableaux de bord
/GMAO : Calcule du planning de maintenance des moyens
/BASOR : Plage d’ouverture par jour des moyens
/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
/CBA : Consolidation & génération du prévisionnel d’achat
/BILAN
/CYCLAR : mise à jour des moyennes de cycle gamme
(/MRP : mise à jour des données PDP et PIC)

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

Les traitements ci-dessus étant effectués automatiquement par Hélios ERP, il est important de bien comprendre le fonctionnement de chacun des outils appelés. Chacun de ces outils possède un écran de paramétrage permettant de gérer ou d’adapter des stratégies différentes selon les organisations et les besoins de nos clients. L’outil central de la mise en place de cette stratégie est l’analyse de la couverture du carnet de commande client.

3.1. /PROG_PROD : Programme de production Helios.

Cette tâche permet d'intégrer le plan de production Helios, elle est utilisable dans le cadre d'un lancement journalier des traitements dans la mesure où elle ne supprime pas les Ofs prévisionnels présents. elle permet de générer des Ofs fermes

But : Intégration des Ofs du plan de production Helios.

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 (Voir paragraphe suivant).

Rappel concernant la tache /PROG_PROD :

Basé sur le dernier modèle Helios 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.

3.2. /PDP et /PDP /L - Le générateur de POFS

La commande /PDP permet de générer les POFs.

Cependant il comprend 3 modes, le lancement manuel par le module CBN Prévisionnel est déconseillé, le lancement automatique est à privilégier.

Ici le but est de traduire tous les besoins du carnet de commandes non couverts par du stock et des OFs et tous les besoins déclarés dans Helios PDP en POFs. Ces POFs sont régénératifs, c’est à dire à chaque nouveau calcul (full), ils se suppriment et se recréent au besoin.

Ils ont la gamme (quel que soit son statut) applicable, les besoins applicables au moment de leur génération.

Les POFs suivent les mêmes règles de génération que les OFs, c’est-à-dire lancement groupé d’articles, la gestion des qtés éco /lot éco (que sur les fins de branche). Cependant la gestion des lots max égal à 1 ne s’applique pas (dans le but d’éviter un volume très important de POFs)

Il n’est pas conseillé d’appliquer de filtre sur les types de ligne de commande, ni sur la gestion des stocks.

Les POFs sont générés de la manière la plus simple, ils doivent être suivis des tâches indiquées pour être jalonnés et avoir leurs besoins en composants et matières traduits.

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

Il s'agit de la tache /PDP avec le 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.

Le PDP va juste générer les POFs. Les jalonnements et le calcul des besoins matières et composants seront effectués par la suite des traitements (R_OFS_PREV et DERES_PDP)

Voir les paramètres de gestion : Paramétrage/Plan de production

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

Puis il génère les OFs 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.

Log du /PDP avec l’option minimaliste cochée

3.2.2. /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 des quantités en commande. Cette tâche remplace la tâche /PDP.

Nota : on parle des quantités commandées, cela ne traite pas les quantités manquantes d'article fils dans le cas de surproduction d'article père par rapport au quantité commandée

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 /PDP /L

Attention ce mode ne supprime pas les POFs déjà générés, cependant ces POFs sont complétés de tous les manquants article détectés par l’analyse de couverture des commandes client.

Résumer du principe détaillé

/PDP /L

Conservation des OFs prévisionnels existants
Basé sur les trous détectés par la couverture
- Trou = Besoin en article, déclaré manquant dans le tableau de suivi de couverture
Donne une liste d’articles manquants par besoin client
- Référence / Qté / Date de besoin / Commande client
Horizon de calcul de couverture : le plus grand possible également nécessaire au R_OFS_PREV et à la DERES_PDP
Paramètres pris en compte lors du traitement de la liste
On 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 OF prévisionnel
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 lancements groupés
- Insertion des OFs prévisionnels dans le tableau de couverture
- 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
La génération du POF est mise à jour dans le tableau de couverture pour lequel il a été généré

Après la génération des manquants en POFs, tous les POFS existants ont leurs gammes et phases rafraîchies.

3.2.3. Générateur d'OF

Avec la mise en place de ces tâches, il est fortement recommandé de fonctionner avec le principe d’affermissement de POF en OF via le module suivi de planification / Liens / Basculer OFs Prévisionnel. C’est le meilleur moyen de piloter ce que l’on souhaite envoyer dans son atelier.

Le risque que l’on peut rencontrer le cas échéant (avec le module besoin), c’est d’avoir des surplus de POF qui passeront à une priorité 25, qui ne seront donc pas remis en cause par la couverture et garderont une date probablement erronée.

3.3. /COUV_NEW ou /COUV_NEW_FULL : 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. Elle remet tout en question en fonction des dates des besoins des articles, des priorités du carnet de commande, de l’avancement des OFs et des commandes d’achats encours.

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.

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

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)

Elle apporte des gains fonctionnels notables par rapport à l'ancienne tâche de la version 2.4 de Hélios ERP, notamment la prise en compte des indices articles, des approvisionnements partiels et des rechanges, qui n'étaient pas gérés.

A la fin du calcul, la couverture est connue.

Exemple de log généré :

Résumer

Le calcul de couverture est le cœur de toute l’organisation de production et d’achat :

Cette couverture va prendre tout le carnet de commandes restant à livrer, le trier et ensuite affecter au besoin le plus urgent le stock ou l’encours de production le plus avancé.

On peut résumer ainsi par ce postulat :

« Le plus en avance pour le plus urgent »

Fonctionnement de base :

D’un côté, le carnet de commandes est mémorisé (attention en fonction du paramétrage sur les clients, types de lignes, horizon le plus grand possible)

Ce carnet de commandes est trié par date de livraison (ou par date recalée suivant paramétrage), chaque commande a donc une priorisation.

De l’autre côté, tous les articles en stock et tous les encours de fabrication (OFs et POFs) sont rassemblés, ces encours sont classés par avancement. L’avancement est déterminé par :

Type de production : OF puis POF
Code article
Statut de l’OF (T, EC, D, EA) et du POF (D, EA)
Cycle restant (suivant paramétrage) sinon suivant le nombre de phases terminées pour les OF EC.
Rang de l’OF
Procédure 1^er article
Numéro d’OF

Pour information :

Le cycle restant n’est applicable qu’avec l’option jalonnement interphase appliquée.

Le cycle restant somme sur les phases internes non commencées les cycles interphases (cycles interphases ou temps de la phase + temps d’attente) de chacune et le délai de sous-traitance restant à réaliser (si phase encours : différence entre la plus petite date de livraison (ou recalée) par rapport à aujourd’hui, si phase non commencée c’est le TT/24)

Les paramètres de gestion : Paramétrage/Analyse de la couverture

Prendre en compte les composants de la nomenclature dans le calcul de la couverture d’un article en commande.
Prendre en compte les équivalents pour couvrir le besoin en composant.
Prendre en compte les matières de la nomenclature dans le calcul de la couverture d’un article en commande
Prendre en compte les équivalents pour couvrir le besoin en composant.
Pour prendre an compte le seuil de sécurité article dans le calcul des articles disponibles en stock.
Si coché : permet de faire avancer les OFs car considère le rebut éventuel comme pièce bonne (conseillé) si décocher => Pas d’affectation de besoin sur les OFs présentant des pièces litigieuses et les OFs sont passé en priorité 30.
Prendre en compte la date de livraison ou la date recalée de la ligne de commande client.
Permet de rafraîchir le stockage des nomenclatures : stockage nécessaire afin d’optimiser les calculs et de permettre une exploitation des résultats
Permet de rafraîchir le stockage des nomenclatures dupliquées : stockage nécessaire afin d’optimiser les calculs et de permettre une exploitation des résultats.
Lors du recalcul manuelle, permet de garder les mêmes commandes mais remet à jour ou pas les priorités.
En fonction des dates de disponibilité ou des dates rejalonnées mise à jour du carnet de commande (champ date de liv. prévisionnelle).
Scinder la mise à jour des OFs du calcul de la couverture. Permet de calculer les avancements de commande tous les jours sans avoir d’impact quotidien sur les OFs.
Permet d'autoriser la tache /R_COUV à mettre à jour les dates de début et de fin d'OFs.
Autoriser pour les OFs de réappro de stock que la date de fin de la couverture soit supérieure à la date de fin de l'OF.
Mettre à jour les types de ligne du PDP après le calcul des priorités des commandes.
Faut il réapprovisionner les stocks de consignation en tenant compte des seuils maxi ?
Liste des clients sur lesquels on souhaite calculer la couverture. Si aucun client n'est basculé alors par défaut aucun filtre n'est appliqué.
Listes des types de ligne de commande client sur lesquels on souhaite calculer la couverture.
Nombre de jours pris en compte pour calculer la date max de livraison au-delà de laquelle on ne veut pas calculer de couverture.
Calculer la couverture sur les lignes de commande qui ne sont pas passées au CBN, dont la quantité lancée + réservée + livrée = 0.
Méthode de calcul optimisée par rapport à l’origine (permet de gérer des nomenclatures volumineuses en un temps minimum).
Utiliser le statut en attente ou encours des lignes de commande client pour définir les priorités des articles en commande.
Calculer l'avancement des Ofs en cours, en basant le calcul sur le cycle restant.

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

Voir les paramètres de gestion : Paramétrage/Gestion des cycles

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

Détail du calcul

Principe du calcul

Le carnet de commandes récupère sur chaque ligne de commande la nomenclature (d’articles) demandée sur chaque article commandé. Il s’agit ici de la nomenclature théorique présente sur les données techniques

La nomenclature récupérée sur la ligne de commande peut être celle présente sur l’OF si la commande et l’OF ont un lien fort via la gestion des verrous.

Réalisation d’un « Calcul des Besoins Brut » sur chaque ligne de commande.

L’objectif est de déterminer le placement dans le temps de tous les besoins et ainsi de donner au CBB le plus urgent le stock ou l’encours le plus avancé.

Toute la nomenclature est décomposée sur chaque ligne de commande (il n’y a pas de prise en compte des stocks et encours qui pourraient la couvrir, ce sera fait plus tard)

Le jalonnement de tous ces besoins théoriques d’articles dans le temps est effectué, ce jalonnement tient compte du mode de jalonnement à appliquer (Temps gamme / Cycle gamme / Cycle CDC / Temps d’attente)

Après avoir détaillé tous les besoins dans le temps, l’algorithme d’affectation aux stocks et aux encours les plus avancés est réalisé :

Pour cela on recherche le besoin d’article le plus urgent non encore affecté pour un père (tout en vérifiant qu’il n’y ait pas de besoin également de cet article en tant que fils avec un besoin plus urgent, si oui on pose également ce fils) et ensuite on recherche les affectations pour servir ces besoins (si aucun besoin n’est nécessaire pour ce nœud de nomenclature alors on solde tous ces fils).

Ici on est sur des traitements récursifs, c’est-à-dire qu’étape par étape, toute l’affectation de la décomposition du carnet de commande est faite au fur à mesure.

Remarque :

En gestion avec des verrous la recherche est simple, il faut que l’élément verrouillé soit en stock réservé pour la commande ou sur un OF encours de fabrication dédié (verrouillé avec la ligne de commande).
Le paramétrage du « seuil de sécurité » et de la prise en compte des « pièces en litige » a aussi un impact sur le calcul

Détail du calcul

Duplication des nomenclatures sur les lignes de commande
- Si verrouillage alors dossier technique de l’OF dédié
- Sinon dossier technique actuel
Basé sur le CBB
- Décomposition en besoin article du carnet de commandes non livré
- Jalonnement de chacun des éléments
Un algorithme détecte le besoin article le plus urgent libre de contrainte
- Le stock, l’encours de production ferme ou prévisionnel y est associé
- En fonction de l’affectation réalisée le besoin fils est remis en question
- Cette procédure récursive se déroule jusqu’à avoir traité tous les besoins articles détectés par le CBB
Les besoins en composant et matière ne sont pas pris en compte
Les dates de lancement sont calculées à la fin du traitement
Priorisation du carnet de commandes
- Devient secondaire : uniquement si un même article à une même date de besoin pour 2 lignes de commandes
- Remplacé par l’utilisation du CBB, Calcul des Besoins Bruts
  - Existe déjà dans la couverture
- Permet de calculer les données nécessaires à la gestion Kanban
CBB : principe
- Décomposition du carnet de commandes en besoin article sur tous les niveaux de nomenclature
  - Pas de de prise en compte des stocks
  - Pas de prise en compte des encours de fabrication
- Jalonnement de chaque besoin article
  - Tient compte des paramétrages de jalonnement généraux
    - Temps gamme / Cycle gamme / Cycle CDC / Temps d’attente
    - En temps d’attente
      - Jalonne sur le calendrier société
      - Lot maximum de lancement
      - Prise en compte du chevauchement de nomenclature
      - Délai de sécurité
    - Critère essentiel dans la détermination des priorités
  - Traitement du CBB
    - Détermination du besoin article le plus prioritaire (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 et même vérification à Traitement récursif
      - Si non, traitement de l’article (idem couverture standard)
        Si aucun besoin n’est nécessaire pour ce nœud de nomenclature alors on solde tous ces fils
      - La fin de la récursivité nous ramène à la première étape et un nouvel article prioritaire est déterminé et traité de la même façon
      - Les priorités ci-dessus sont stockées à chaque positionnement traité par l’algorithme dans la table du CBB

En conclusion, le calcul de couverture refait les liens entre les besoins clients d’article et les stocks / OFs / POFs.

3.3.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 Non conformité 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]

3.4 Les retour sr OFs et POFs

La correspondance entre les encours de productions (OFs et POFs) avec les besoins clients a été calculé par l’analyse de couverture, ici on va venir réaffecter sur les OFs et les POFs, leurs nouveaux besoins et donc mettre à jour leurs dates, leurs commandes clients affectées, leurs priorités, les liens pères et fils (nomenclature) et jalonner toutes leurs phases pour couvrir leur nouvelle date de réalisation.

Attention ici n’est expliqué que le retour avec l’option « jalonnement à la phase » activée

Mise à jour de la ligne de commande affectée à l’OF, mise à jour dans l’onglet Couv ligne commande, le lien initial de la commande est placé en besoin pour le stock (ligne 0/0**).

Si un verrou existe entre la commande et l’OF on retrouve dans l’onglet couverture le lien entre la commande et l’OF identique au lien initial de l’OF

Mise à jour des priorités de couverture dans les OFs

Recopie dans la priorité de couverture de celle de l’OF si l’Of est utilisé dans la couverture

25 à Pas d’affectation faite dans la couverture
1. NB : Les OF de réappro de stock sont exclus
30 à Pas d’affectation faite par la couverture mais
1. OF avec toutes les pièces en litige
2. Les pièces litiges considérées comme mauvaises (cf. paramétrage analyse de la couverture)
40 à OF de réappro de stock généré par seuil de réappro et sans besoin affecté
Priorité des Frais de la ligne de commande client affectés (la plus grande si plusieurs frais ou plusieurs commandes sur l’OF)

Mise à jour des nomenclatures sur les OFs

Les liens entre OFs sont recréés en fonction des affectations réalisées par l’analyse de couverture.

Ces liens sont tous revérifiés en faisant des liens unitaire pièce par pièce entre chaque OF : cette fonction est appelée gestion des « surnomenclatures » dans Hélios. Cette optimisation vise à ajuster au mieux les liens fils et père entre chaque OF (à cause des quantités en production différentes des quantités en commandes, des OFs ayant un fils en partie réservé en stock et sur un encours…)

Les liens sont maintenant découpés phase par phase, c’est à dire que les nomenclatures d’OFs sont ramenées sur chaque phase. On a maintenant tous les besoins de production liés entre eux phase par phase.

Pour donner suite à la constitution des nomenclatures de phase, on est capable de déterminer des phases sans lien, ces phases sans lien ont donc comme référentiel de fin la date de besoin demandée pour elles dans l’analyse de couverture.

Il peut s’en suivre le jalonnement de toutes les phases de manière récursive sur l’ensemble des phases des OFs non soldés.

En finalité la date de début et de fin des OFs sont données respectivement par la plus petite date de début sur les phases de l’OF pour la date de début et la plus grande date de fin sur les phases pour la date de fin.

Remarque - Axone PDP

Priorité : la priorité des OFs en gestion PDP est en gestion 95, cette priorité descendra aussi sur tous les OF fils.

Jalonnement : les dates de couverture ne sont pas mises à jour sur les articles en gestion PDP, le référentiel est donc la date de fin déjà présente sur l’OF.

La couverture a permis de créer la nomenclature de phase dans le cas où un OF en gestion PDP est un OF père, en conséquence la date de besoin de l’OF père permet de jalonner toute la nomenclature des OFs fils phase par phase

3.4.1. /R_OFS : Calage 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 : Le calcul distingue les OFs « utiles » c'est-à-dire les Ofs dont les éléments en cours de fabrication sont nécessaires pour couvrir un besoin exprimé par le carnet de commande des autres.
- Reprise de celle de l’OF lorsqu'elle était renseignée.
- 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 la couverture le remet en question,

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

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

Une fois le positionnement de toute la production par le retour sur OF et sur POF, on peut enclencher la déréservation.

3.5. La déréservation

Pour faire simple, la déréservation a pour objectif de redistribuer le stock et les encours à tous les besoins les plus urgents. Pour cela, 4 actions lui sont associées :

Redistribuer le stock article couvrant des besoins d’articles dans la couverture sur des commandes clients.
Redistribuer les besoins en commande d’éléments en gestion négoce.
Recalculer les besoins en composants et matières pour chaque OF.
Recalculer le statut des commandes et des OFs

La redistribution des articles ne se fait que si le paramétrage de suppression des lancements dédiés est coché (c’est plus que conseillé)

En premier lieu, le stock article est libéré de toutes les réservations déjà présentes, à l’exception des réservations existantes sur des commandes ou pour des OFs présentant un verrou. Ensuite tous les OF non soldés et ne présentant pas de verrou sont libérés en encours de fabrication pour stock.

Dès lors, pour les articles en commande détectés comme couverts par le stock et/ou de l’encours par l’analyse de la couverture, une réservation est créée dans le stock article, le statut de la ligne de commande est également mis à jour.

En second lieu, les stocks composants et matières vont être redistribués aux besoins les plus urgents. Pour cela, un ordre de priorité est donné à chaque besoin. Les besoins sont les besoins non soldés présents sur tous les OFs non soldés et toutes les commandes clients de négoce (encours ou en attente) restant à livrer.

Une remarque ici sur la constitution de cette liste, tous les OFs ayant une priorité >=50 et toutes les commandes de négoce seront traitées dans un premier calcul. Les autres OFs avec une priorité < 50 seront traités dans un second temps. Cela permet de ne pas donner du stock à des OF non vivants et en priorité 25, on donne les éléments en stock d’abord aux besoins à livrer aux clients.

Une fois ces listes d’éléments à traiter pour affecter le stock, on les trie par la date de besoin de la 1ère phase qui le demande, les commandes de négoces sont également placées dans cette liste mais ordonnées sur la date de livraison, ou la date recalée de la ligne de commande client.

On supprime toutes les réservations sur les stocks, encours de commandes et manquants pour les matières et composants.

On recalcule besoin par besoin leur couverture en stock et encours suivant cette règle :

On réserve le besoin dans le stock principal de l’élément si le disponible (le format) le permet
Si pas suffisant, on cherche à réserver dans le stock de consignation de l’élément
Si pas suffisant, on cherche à réserver dans le stock des liens équivalents
Si pas suffisant, on cherche à réserver l’encours de commande d’achat de l’élément.
Si pas suffisant, on cherche à réserver l’encours de commande d’achat des liens équivalents.
Si pas suffisant alors un manquant est déclaré sur le besoin principal

Nota : N’est considéré en stock qu’un élément non périmé à la date du besoin, et dont la qté dispo en stock > au stock de sécurité.

Une fois le calcul effectué pour tous les besoins de chaque OF et commande de négoce, le recalcul des statuts des OFs et des commandes clients de négoce est effectué. Il s’applique pour tous les OFs en attente et dispo, tous ces OFs sont placés disponible et le statut en attente sera écrit sur tous les OFs pour lequel il

Existe une nomenclature d’OF (il a besoin d’OFs fils verrouillés)
Existe une réservation sur encours de production article pour l’OF (il a besoin d’OFs fils libres et donc en cours de fab pour le stock)
Existe une réservation sur un encours de commande d’achat pour l’OF (des besoins restants à servir, sont réservés sur des commandes frs)
Existe un manquant (composant, matières ou articles) déclaré pour l’OF

La déréservation s’applique également aux POFs (DERES_PDP)

Le principe et les règles sont les mêmes que pour les OFs dans l’étape de DERES_PH.

Cas particulier du Négoce :

Dans la DERES_PH

Pour chaque besoin de composant de négoce, on calcule la plus grande date de besoin du composant de négoce pour un OF
On ne remet en question que les lignes de commandes de composant de négoce qui ont une date inférieure au besoin ci-dessus

Dans la DERES_PDP

Supprimer les manquants et réservations pour les lignes de commande qui ont une date de livraison supérieure au dernier besoin du composant pour un OF ferme
Inclure dans le processus les lignes de commandes clients dont la date de livraison dépasse la date de dernier besoin du composant pour un OF ferme
Prendre en compte les commandes de négoce dans le processus

Sinon on se retrouverait avec des commandes clients de négoce qui réserveraient le stock sur un horizon compatible avec les besoins de production. Le restant poserait des réservations prévisionnelles et déclarerait du manquant prévisionnel

3.5.1. /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 de la version 2.4 et une partie du traitement /ANA_BES concernant la mise à jour des statuts des Ofs.

Voir les paramètres de gestion : Paramétrage/Besoin

Les paramètres pris en compte :

Création des OFs si détection de manquants dans les nomenclatures. Option cochée ou non un fichier trace l’ensemble des manquants.
Activation de la suppression totale des lancements dédiés

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

Cas particulier : besoin d'un même élément divisé sur plusieures phases

Exemple : un composant de besoin 10 est divisé en besoin 6 à la ph20 et 4 à la ph80
le calcul DERES_PH calculera un besoin de 10 pour la 1ère phase
çàd que la date de besoin totale de l'OF sera toujours la urgente des phases

Résumé du principe détaillé DERES_PH

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 sauf pour les articles et commandes demandant un verrouillage entre les commandes et OF, et pour les réservations portant sur un retour client et sur des BL en attente.
- Suppression des nomenclature d’OFs (sauf si un verrou existe entre père fils)
- Transformation des OFs en encours de stock (sauf si un verrou existe entre la commande et l’OF)
- Pour les articles en commande
  - Les affectations effectuées par la couverture 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 OF non soldé et chaque besoin non soldé de l’OF
      - Calcul du reste à sortir pour l’OF
      - Priorité (>= 50 sont ramenés à 50)
      - Date de besoin de la phase de l’OF
    - Tout le carnet de commandes de négoce
      - En fonction du reste à livrer
      - Priorité est figée à 50
      - La date de livraison ou date recalée détermine la date de besoin

(voir ci-dessus)

Tri de la liste ci-dessus par
- Priorité
- Date de besoin
Parcours de la liste
- Pour chaque élément
  - On affecte le stock principal de l’élément
  - Si pas suffisant on affecte le stock de consignation de l’élément
  - Si pas suffisant on affecte le stock des liens équivalents
  - Si pas suffisant on affecte l’encours de commande d’achat de l’élément.
  - Si pas suffisant on affecte 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 s’il
      - 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
    - Calcul du statut des commandes si la commande a toutes ces qtés restant à livrer réservées en stock => statut encours

3.5.2. /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,
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.
- Calcul du statut des POFs,

Performance constatée

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

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

À la suite des recalculs des besoins pour les OFs et POFs, l’objectif est de mettre à jour l’affichage de l’analyse de la couverture sur les commandes clients en donnant l’état des besoins composants et matières pour chaque commande.

L’objectif est également de remonter les dates de disponibilités des différents besoins sur les OFs et POFs. Ces dates de dispo rentrant en compte dans la planification de chaque phase.

Cette tâche permet de mettre à jour la couverture des commandes clients avec mise à jour des dates de disponibilité des composants et matières.

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.

Le résultat de l'analyse de la couverture est visible dans la fiche article : Outils/Analyse couverture : Carnet de cmde.

Exemple :

Principe détaillé

Mise à jour de la couverture commande client
- Chargement de la couverture réelle des besoins de chaque OF ferme et prévisionnel
  - Pour chaque composant et matière
  - 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
- Mise à jour de la couverture commande client
  - Parcours des nomenclatures des lignes de commande client par priorité du CBB
  - Pour un couple article / composant (ou matière) on connait la liste des OFs (fermes ou prévisionnels) qui couvrent l’article et le nombre de pièces 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’OF 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 fournisseur 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 couverts par des OFs fermes 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’OF avec besoin
        Phase d’OF
      - Remontée des données de disponibilité dans les tables de planification

3.7. /GMAO : Pour calculer le planning de maintenance des moyens.

Pour chaque maintenance ayant une périodicité > 0 et une date saisie (première intervention ou dernière intervention), un planning prévisionnel se calcule.

Une tache planifiée permet de lancer le calcul : /GMAO

Les opérations de maintenance se créent au statut prévisionnel. La première maintenance prévisionnelle pour un moyen passe au statut à confirmer si elle est à effectuer dans les 30 jours.

3.8. /BASOR : Calcul des ouvertures et calendriers des ressources.

3.9. /PLANIF : Ordonnancement à capacité finie et infinie.

3.10. /CBA : Calcul des besoins achats.

Le CBA est une fonctionnalité permettant de générer un carnet de commande d'achat prévisionnel. Il analyse tous les besoins achat issus du CBN, CBN Prev, Réappro de stock, demande d'achat sur les composants, matières, consommables, outillage, sans référence et génère de commandes prévisionnelles.

De plus cet algorithme permet de regrouper les qté de commande en fonction des horizons flexible (semaine) et prévisionnel (mois) définie sur la fiche fournisseur. Il est également connecté au moteur de recherche de prix utilisé dans les commandes fermes de manière à récupérer l'ensemble des informations sur les contrats ou catalogue de prix.

Si il n'y a pas de valeur renseigné le système prendra 14 semaine comme valeur par défaut pour le flexible puis mois par moi pour le prévisionnel.

Les besoins échus sont regroupés au mercredi de la semaine actuelle.

Sur l horizon flexible (HF) les besoins sont regroupés aux mercredi de chaque semaine.

Sur l'horizon prévisionnel (HP) les besoins sont regroupés sur le dernier mercredi de chaque mois

Flexible : Cas sans gestion de Qté Mini et de format d’achat :

Horizon flexible de 2 semaines donc pendant deux semaine nous allons regroupé les commandes avant de passer a l'horizon prévisionnel.

Nous aurons donc deux lignes de commande prévisionnel :

1 ligne avec une Quantité de 1 X 31 U et une date de livraison au 04-12-2024

1 ligne avec une Quantité de 1 X 27 U et une date de livraison au 11-12-2024

Flexible : Cas gestion de Qté Mini de 50 et de format d’achat

Le premier regroupement aura la date convenue par le regroupement des éléments de la semaine positionner un lundi

Mais le second regroupement comme il est déjà couvert par le restant du premier regroupement il aura la même date de livraison que le premier regroupement

Deux lignes de commande prévisionnel :

1 ligne avec une Quantité de 1 X 31 U et une date de livraison au 04-12-2024

1 ligne avec une Quantité de 1 X 15 U et une date de livraison au 04-12-2024

Prévisionnel : Cas sans gestion éco

On prend le dernier mercredi du mois comme date de livraison pour les regroupement, même principe que le Flexible si le regroupement est couvert par le reste on prendre la date de livraison du regroupement d'avant si il n'y a pas assez de reste on prendra le dernier mercredi du mois suivant

3.11. /BILAN : Calcul des Bilans

3.12. /CYCLAR : mise à jour des moyennes de cycle gamme

Mise à jour des moyennes de cycle gamme et MAJ du Cycle de la fiche article en fonction du paramétrage de jalonnement

4. Mise à jour de la charge

/CHARGE

Pour mettre à jour la charge.

Fonctionnement :

Se base sur le jalonnement des OF.
Puis sur le jalonnement des phases.
Positionne la charge en fonction du t=0 :
- Si OK suit le jalonnement des phases
- Si Ko fait du au plus tôt à partir de t=0 en essayant de rattraper le fil du jalonnement des phases et terminer soit comme le jalonnement, soit au mieux.
- Tient compte des Appros et de la disponibilité de couverture des OF pour définir une date initiale au lieu du t=0.

Objectif : Voir la charge / capacité de l’entreprise

NB : Peut être passée sous deux formes :

- En semaine : pour l’état d’avancement quotidien des OF,
- Suite à la réorganisation (a, b et c) pour un impact bien plus lourd, c.à.d. le repositionnement et l’avancement au quotidien.

5. Les autres tâches de gestion d’Helios ERP

/CYCLAR : Pour calculer tous les cycles d’articles avec mise à jour des gammes.
/SIMAR : Pour calculer la simulation des articles pour le coût et les bilans.
/CALSTO :
/OPTIMA : Pour lancer la procédure d’optimisation du manque avant lancement des achats.
/CBN : Pour lancer le CBN en auto. Il suit le paramétrage.
/PIC :
/POINTAGE
/MRP
/ISO : Pour lancer la gestion des programmes seuls sans passer par Helios ERP.
/AGORA : Accès à Agora
/AR : Analyse de l’AR de la messagerie pour la gestion documentaire et la qualité.
/EDIs : Pour lancer l’automate de récupération des commandes ST avec mise à disposition sur site FTP.
/EDI /SCMD :Traitement EDI Commandes ST
/EDI /SBL : Traitement EDI BL ST
/EDI /SFAC : Traitement EDI Factures ST
/EDI : Pour l’intégration des messages EDI.
/EDI : Interface EDI
/EDI /AUTO Traitement EDI automatique
/EDI /CCMD Traitement EDI client.

6. Divers :

exe/POWERPICK : Pour le pilotage d’armoire rotative KARDEX en Entrées/Sorties de stock.
HII_PLA /S : Pour l’intégration du suivi de pilotage d’atelier.
HII_CLE/S ou HII_CLE/ALL : Pour la gestion des licences Helios ERP.
HII_CPT /C Interface Compta Client.
HII_CPT /F Interface Compta Fournisseur.
HII_CPT /S Interface Compta Sous-traitant.

Browser not supported