ATELIER 2 - ARTICLES

Réunion du 20.10.2004

Cet atelier a traité la gestion des articles dans Baan, les différents paramètres de gestion et de réapprovisionnement et les données additionnelles article. Au cours des discussions, certaines incohérences dans les données ont été relevées, un certain nombre de questions d'ordre fonctionnel ont été soulevées, certaines demandes d'améliorations ou de développements ont été formulées.

Vous trouverez ci-dessous le récapitulatif de ces différents points.

1-Correction des données :
Les listes relatives aux articles incohérents vont être fournies au magasin par IT/AIS à des fins de correction.

2-Demandes de statistiques:
Les magasins souhaitent obtenir les listes suivantes:
-Liste des articles EDI Bossard avec totall nombre de demandes et quantités cumulées sur une année par article
-Liste des articles au magasin ZZ avec du stock
-Liste des articles en épuisement non rattachés au magasin ZZ
-Liste des articles rattachés au ZZ comportant des associations avec d'autres magasins et des emplacements
-Liste des articles, magasin autre que ZZ avec poids = 0

4-Feedback EDH :

Il sera abordé en détail lors d'une réunion spécifique. Toutefois, un certain nombre de modifications ont été demandées pour assurer la transparence entre Baan et EDH :
- Affichage feedback EDH (transaction cddev020m000) à optimiser. Revoir index et présentation des données
-rajouter index sur table tdsls040 (en-tête ordres de vente) pour pouvoir rechercher un ordre de vente à partir de la ref. EDH

Pour assurer une transparence totale, nous pourrions utiliser les nouvelles fonctionalités offertes par Baan IV c4 qui permettent de gérer des numéros à 7 chiffres (au lieu de 6 actuellement). La référence EDH pourrait être la référence de l'ordre de vente Baan.
Avantages:
-lisibilité et traçabilité facilitées
Inconvénients:
-EDH utilise une seule plage de numérotation pour tous les documents. On aurait par voie de conséquence des trous dans la numérotation des ordres de vente Baan
-nécessité pour la saisie des demandes manuelles de respecter les plages prévues sous peine de clash si on utilise la fréquence réservée à EDH.

Point à débattre avec les magasins avant une décision.

5- Données articles:

5.1 - Ecrans de saisie:
Page 2 - Donnés stock. Actuellement, les données cumulées de stock sont affichées dans cet écran. Par exemple, le stock est le stock total de l'article pour tous les magasins auxquels il est associé. Les gestionnaires de produit souhaiteraient rajouter les données de stock pour le magasin principal de l'article, à savoir : stock réel, stock bloqué, stock en commande, stock réservé, stock économique et quantité en appel d'offres
Page 3 - données sur l' achat : ajouter la date de fin de validité du contrat

5.2 - Prix de revient:
Selon les magasins, il n'est pas possible de recalculer le prix de revient en cas de commandes en cours. Après vérification, il y a effectivement un contrôle lors de l'appel de la sous-session qui recalcule le prix de revient et l'écran ne s'affiche pas si un stock économique existe. On pourrait enlever ce contrôle (en modifiant la session) mais, en attendant, il est possible de recalculer le prix de revient depuis la session principale 'calcul prix de revient' et cela fonctionne. De toutes façons, les prix de revient sont recalculés automatiquement chaque samedi (ainsi que les prix de vente).
Par contre, lors du recalcul, on ne peut changer automatiquement les prix sur les commandes en cours. Faire un traitement spécifique pour effectuer cette mise à jour serait extrêmement lourd car il faudrait aussi mettre à jour les tables financières. Ce qu'on pourrait faire, c'est générer la liste des lignes de commande concernées pour faciliter la mise à jour manuelle. Décision FI/LS

Le Epool déplore de devoir calculer le prix de revient lors de la création d'un article. Ce calcul n'est pas obligatoire et il est possible d'attendre le prochain calcul par batch, d'autant plus que le Epool n'utilise pas ce prix pour calculer le prix de vente (qui est un prix de location). La prochaine fois que Epool crée un article, nous proposons de le faire ensemble afin d'éclaircir ces problèmes fonctionnels spécifiques.

5.3 - Taux de change:
Pour l'instant le taux utilisé dans Baan pour les calculs de prix de revient est le taux de change interne, comme dans Qualiac et ce taux est actuellement de 1.56 pour l'Euro. Utiliser un autre taux comme base de calcul implique un changement des règles actuelles et nécessite une négociation préalable avec les secteurs concernés. En outre, lors de l'intégration des commandes Baan dans Qualiac, c'est le taux interne qui est appliqué.

5.4 - Codification du scem :
Depuis plusieurs années, le dernier digit du Scem n'est plus une clé spécifique comme initialement. Cette clé peut donc être utilisée comme un digit significatif pour la définition d'un article. A utiliser toutefois avec soin pour éviter des clash entre articles.

5.5 - Codes Signaux:
La statistique affichée lors de la présentation fait apparaitre de nombreux code de type E% dont certains à double emploi, les libellés correspondants ne satisfont plus les magasins et il faudrait créer des codes composites pour par exemple les produits chimiques en épuisement.
La liste va donc être revue par FI/LS afin de supprimer les codes inutiles, mettre des libellés plus explicites et créer les codes manquant (chimique epuisement, etc..)

5.6 - Textes articles:
Les textes articles sont créés dans une langue. Pour pouvoir éditer les textes si la langue de la commande change, il faut créer une occurrence du texte dans l'autre langue (Anglais ou Français). On peut le faire dans la gestion des textes en lançant l'option 2 de la session, Toutefois, il n'existe pas de traducteur intégré et le texte recopié sera identique au texte source. Il faudra ensuite effectuer la traduction à la main, si nécessaire

Sur le plan fonctionnel, il faut rappeler que les textes créés ou recopíés doivent être structurés comme suit:
-Mot-clé 1 = scem
-Mot-clé 2 = description courte
-Mot-clé 3 = scem
-Mot-clé 4 = scem
Ces conventionss, si elles ne sont pas respectées, risquent de rendre la recherche d'un texte extrêmement difficile voire impossible et il n'apparaitra pas sur les documents le concernant (commandes, relances, etc...)

5.7 - Recopie article:
la plupart des articles sont créés par recopie. Toutefois, un certain nombre d'informations, si elles ne sont pas vérifiées risquent de poser problème ensuite (par exemple, date de création, date 1er ordre, paramètres de réappro, paramètres de stock, textes).
Solution proposée : FI/LS doit faire la liste des champs qu'il ne souhaite pas recopier et IT/AIS modifiera le programme de recopie en conséquence.

5.8 - Groupe rabais :
Ce champ sert à empêcher la reclassification d'un article dans un autre groupe de marge. La convention est de mettre dans ce champ la valeur contenue dans le champ 'groupe de marge'.
Peut-être pourrait-on utiliser un autre paramètre (groupe statistique ?), pour gérer cette fonctionalité.

6- Contrôle de qualité :

Le contrôle de qualité est-il nécessaire pour les articles ne nécessitant pas un contrôle à l'extérieur. La réception effectue ne suffit-elle pas dans la plupart des cas?Ce problème sera discuté lors de l'atelier concernant la partie achat (atelier 4).

FI/LS souhaite un emplacement de quarantaine pour certains articles. Cela ne pose aucun problème : il suffit de définir, dans le magasin concerné, un emplacement bloqué pour la sortie vente. Fonctionalité souhaitée à préciser par FI/LS avant msie en place.

7- Incoterms:

FI/LS voudrait changer la destination pour les incoterms de type DDU. Pour l'instant la destination est le site de livraison du matériel (Meyrin ou Prévessin). Pour les incoterms EXW, nous avons résolu le problème en créant une occurrence EX1.On pourrait soit faire la même chose pour les incoterms DDU, soit modifier le programme de la gestion des ordres d'achat, laisser le champ 'destination' modifiable et l'éditer de la même manière sur le bon de commande.

8- Problèmes de réseau au bât. 73:

Les utilisateurs Baan du bâtiment 73 sont souvent déconnectés de l'application Baan. Cela génère des locks dans les tables et des licences bloquées en plus du désagrément enduré. Les problèmes de réseau dans ce bâtiment ont un caractère récurrent.

Solution proposée : Pour mieux cibler le problème avant de déclencher une intervention des spécialistes réseau, nous demandons qu'une personne des magasins soit désignée pour faire une statistique sur une semaine. Cette personne devrait en même temps qu'elle ouvre le client Baan, ouvrir une session ascii (avec Putty) et, quand ellle perd la connection du client vérifier si la session putty reste active. Elle devrait nous fournir en outre les informations suivantes:
-date et heure de coupure
-utilisateur
-application (client Baan, Baan via Putty, Qualiac, EDH, le Web et d'autres applications)

C'est le seul moyen de pouvoir tracer ce qui se passe et écarter un problème particulier lié soit à l'application soit à un utilisateur (settings du PC, etc..).
Si les tests confirment un problème de réseau, il faudra ensuite contacter un expert pour une analyse plus détaillée.
Il y a un vaste projet de recablage de certains bâtiments au Cern, il faudrait vérifier si le bâtiment 73 fait partie de la liste et quelle est la date prévue pour cette intervention.

9- Nomenclatures :
Baan supporte les nomenclatures de produits, c'est à dire l'éclatement d'un article en divers composants, dans son module' production'..
Cette fonctionalité intéresse les magasins qui y voient différentes applications possibles. Elle sera rediscutée lors du dernier atelier(no 9) consacré notamment aux nouvelles technologies et aux orientations futures.
Il faut toutefois être attentif au fait que l'introduction de nouvelles fonctionalités suppose des tests aprofondis au préalable (impact sur désenlogement, ventes, achats, impact sur le travail quotidien) avant d'être implémentée.

10- Paramètres :
Il faut éviter de tester en solitaire certaines spécifités (notamment en jouant avec les paramètres) car il n'est pas garanti que le résultat escompté sera le bon et des conséquences non visibles immédiatement risquent de se manifester plus tard avec un risque de corruption des données.
Rappelons que Baan est un progiciel. Pour coller aux besoins spécifiques du Cern, nous l'avons paramétré d'une certaine manière. Certains paramètres ou certaines occurences sont supportés, d'autre non. Ceci est la conséquence des choix stratégiques initiaux..
Utiliser d'autres paramètres que ceux initialement prévus et supportés nécessite donc de les tester au préalable (dans la compagnie 222).

A.O.B.:
Dans la mesure du possible les demandes de statistiques faites au cours des ateliers seront satisfaites au plus vite. Les demandes de nouveaux développements feront l'objet d'un document de synthèse qui sera établi à la fin des ateliers, sera rapproché du programme de travail et permettra une redéfinition des priorités en fonction des besoins exprimés par les utilisateurs.