Optimisation du programme de calcul cmp (V10.12)

Owned by Bertrand Littel
Last updated: 12/11/2024 by Sylvie Ulmer
4 min read

Le programme Commerce & logistique/ Traitements/ Calcul des Coûts moyens pondérés a été optimisé.

2 niveaux d’optimisation ont été mis en œuvre:

  • implémentation d’un mécanisme d’interclassement. Cette optimisation a été downgradée sur toutes les versions maintenues de l’ERP.

  • implémentation d’une option de parallélisation avec réservation éventuelle du dossier. Cette optimisation est disponible en version X.12 uniquement.

Aucune différence fonctionnelle n’a été apportée.

Attention, l'interclassement induit un changement dans la logique de surcharge des programmes :

  • Les records SQL doivent avoir un tri commun, ces tris sont initialisés par le programme standard, il est donc interdit de les modifier.

  • Les records SQL doivent extraire une sélection commune, l'ajout d'un filtre à un niveau doit donc possiblement être reporté sur tous les niveaux inférieurs.

 

 

Les modes de lancement

Réservation de dossier sans parallélisation

Ce choix a pour effet de lancer le calcul en une seule fois et en réservant le dossier.

image-20240122-124100.png

Réservation de dossier avec parallélisation

  • Ce choix permet de lancer simultanément (en parallèle) plusieurs programmes de calcul cmp.

  • Chaque programme va traiter une portion de l’ensemble total des articles sélectionnés

  • On peut lancer jusqu'à 5 programmes en parallèle. Néanmoins, l’utilisateur pourra personnaliser ce nombre dans le gttt125_sql.dhsp, le nom de la variable à personnaliser est nbrPrgParallelMax

  • Une autre variable à personnaliser dans le gttt125_sql est la Nbr_Regroupement qui correspond au nombre minimal d’articles à traiter dans chaque programme lancé.

Exemple : On peut définir nbrPrgParallelMax = 3 et Nbr_Regroupement = 1000, cela indique que le calcul CMP ne peut lancer plus que 3 calculs en parallèle et que chaque calcul doit inclure au moins 1000 références.

image-20240122-125129.png

Calcul sans réservation de dossier

  • Ce choix a pour objectif de dispenser l’utilisateur de la contrainte de réservation systématique du dossier, il est recommandé lors du lancement du programme sur une faible plage d’articles

  • Le programme va traiter dans ce cas l’ensemble total des articles sélectionnés en plusieurs calculs en série. Le découpage sera défini dans le gttt125_sql.dhsp via la variable nbrGroupementSerie

  • Il faut définir la variable précédente de façon extrêmement précis afin de ne pas saturer la table de réservation.

Exemple

  • Pour le cas d’une valorisation par dossier, on a besoin de 2 réservations par article (réservation stock + réservation SART). Supposons que la taille totale de la table des réservations = 60000 et qu’on veut laisser au moins 10000 lignes pour le fonctionnements des autres utilisateurs. Supposons encore que le nombre total d’articles sélectionnés est de 300000.

Dans ce cas nbrGroupementSerie = (60000 - 10000) / 2 = 25000

 

  • Pour un cas de valorisation par établissement / dépôt, on reprend le même exemple précédent et on suppose que le nombre de croisements possible entre les dépôts et établissements = 10

  • Dans ce cas le nombre total des réservation nécessaires est de 12 (réservation stock + réservations SART + une réservation SARTCR pour chaque couple établissement / dépôt )

Dans ce cas nbrGroupementSerie = (60000 - 10000) / 12 = 4166

 

Ouvertures

Les ouvertures citées dans le tableau ci-dessous sont nouvelles dans le gttt125_sql, et répondent aux cas cités ci-dessus

Ouverture

Usage

Get_NbreGroupement

Renvoie le nombre minimal d'articles à traiter par programme (en cas de traitement par parallélisation)

Get_NbrPrgParMax

Renvoie le nombre maximal à ne pas dépasser des programmes en parallèle (en cas de traitement par parallélisation)

Get_nbrGroupementSerie

Renvoie le nombre de découpage souhaité en cas de traitement par sérialisation

SousReferenceTmp_Selection_Av

Avant sélection des sous-références à traiter, permet d'ajouter des filtres

Tunnel

Il existe un tunnel permettant l’appel de la version SQL du programme en mode piloté.

Le passage des paramètres change: en lieu et place d’une chaine HMP restrictive en volumétrie, il est désormais nécessaire de passer une table temporaire (identifiée par son nom) :

La table temporaire doit contenir les ID des sous références article à traiter.