Cahier des charges SESAM Vitale 1.40 et mise à jour des logiciels

Bonjour,

Je n'ai pas de raison d'incriminer les lecteurs dont je suis équipé pour l'instant. Dès mon installation, j'ai pris des lecteurs compatibles.

Au niveau bug, c'est à dire un comportement anormal par rapport à ce que l'on s'attend du logiciel, je n'ai qu'un exemple. Selon les lots de fabrication, la vignette de remboursement de Panotile pose un soucis à Premium. D'un côté, cette vignette semble différente selon les lots. La lecture du code barre qu'elle porte montre que les deux derniers caractères manquent (non lus, non interprétés, non imprimés, je ne sais pas). Mais selon le module de Premium que l'on utilise, le produit sera reconnu ou non : En vente, la vignette problématique n'empêche pas le reconnaissance de l'article; en réception de commande, il propose de créer l'article.

Pour les effets de bord, cela va être bien plus compliqué car certains d'entre eux se gèreront au niveau local à la main, d'autres pourront être gérés plus globalement au niveau logiciel.

Premier soucis : la plage de codes 950 et supérieurs
Selon la norme, cette plage doit rester libre pour permettre la création de nouveaux articles récemment arrivés sur le marché. Avant la migration, ces articles sont déplacés vers la plage des codes internes (900 et au dessus). Il en résulte que le même article dont le labo nous avait donné le code va se retrouver avec un code différent chez chacun de nous. Pour ceux qui sont membres d'un groupement qui possède ses MDD, il est fort probable que certains d'entre eux ont été créés avec un code dans la plage 950+. Si vous passez vos commandes par télétransmission, cela posera un soucis. Il faut donc que vous preniez contact avec vos groupements pour vous assurer que cette problématique est prise en compte.
Selon le protocole de télétransmission, les articles sont décrits de façon différente. Pour le 171, je n'ai pas d'informations. Pour le PharmaML, l'année 2012 est une période transitoire pendant laquelle les codes 7 chiffres ET 13 chiffres sont transmis. Début 2013, il n'y aura plus que le code 13 chiffres. Il faut donc que vous vous assuriez que vos commandes PharmaML sont bien interprétées par l'informatique de votre fournisseur, qu'il s'agisse de votre groupement, d'un labo quelconque ou d'un grossiste. Il me semble que le risque est limité pour les labos et les grossistes, les articles crées en 950+ étant rarement commandés en pharmaML. Pour les groupements, c'est au coup par coup. Je suis PlusPharmacie. Certains de nos MDD occupaient des codes dans la tranche 950+. J'ai vérifié hier avec l'informatique, les commandes pharmaML passent et sont correctement interprétées pour ces articles qui ont été déplacés.
Pour ceux utilisant des MDD de leur groupement, assurez vous que ceux ci sont bien en train de préparer la transition avant fin 2012.

Deuxième soucis : la codification à 13 chiffres
Ici, cela va devenir assez complexe, car selon la SSII qui vous fournit votre solution, les choix seront peut être différents. Ce qui risque de poser des soucis, c'est la façon dont votre logiciel va réagir quand vous lui présentez un code barre.
Normalement, un code à 7 chiffres sera interprétés comme un CIP7. Le logiciel contient une table de correspondance entre les CIP7 et les CIP13. C'est le minimum syndical. Si ça ne se passe pas comme cela, vous pouvez râler.
Là où le bas blesse, c'est dans la logique adoptée par l'éditeur de logiciel pour les codes à 13 caractères. Les CIP et les ACL sont normalisés. La version à 13 caractères encapsule la version à 7 chiffres. Les 5 premiers caractères sont 34009 suivi du CIP7 et d'un clé de contrôle codée sur un caractère pour un CIP13, 34001 (de mémoire, mais c'est à confirmer) suivi de l'ACL7 et d'une clé de contrôle codée sur un caractère pour un ACL13. Si votre logiciel ne sait pas retrouver ses petits avec les CIP13 ou ACL13, vous pouvez râler.
Reste le cas problématique d'un produit de para qui ne présente qu'un code EAN13 sur son conditionnement. C'est là que les athéniens s'atteignirent... Premium (mon logiciel) semble suivre la logique suivante : S'il ne reconnait pas les 5 caractères d'entête, il cherche dans la base produit pour trouver l'EAN13 si l'article existait déjà. Mais un certains articles ne sont pas reconnus. Ils ne sont pas très nombreux, mais je n'ai pas trouvé de règle pour expliquer la raison de l’échec de la reconnaissance. Ces articles doivent être gérés à la main en rajoutant dans la base produit le code barre de l'EAN13.

Je ne sais pas comment les autres SSII ont traité le problème. Je suis plutôt curieux, j'aimerais bien savoir.

En ce qui concerne les codes Datamatrix, j'ai fait quelques essais: Premium reconnait sans difficulté les codes CIP. Par contre, pour les infos de numéro de lot et de date de péremption, c'est moins brillant. Je ne sais pas si cela se situe dans la lecture, le décodage du code... Certains codes donnent un numéro de lot correct, d'autres pas (soit rien du tout, soit le numéro attendu suivi de caractères supplémentaires). Je n'ai trouvé aucun prodduit dont le Datamatrix contienne la date de péremption. Je ne connais pas les échéances de dates pour la mise en place définitive de ces informations dans les codes Datamatrix. Je ne peux pas dire s'il y a urgence ou pas chez les fabricants.

Rémi

Bonsoir Rémi,

J'ai installé la 1.40 mi-Octobre (cf http://forum.avenir-pharmacie.fr/t298-sesam-vitale-migration-vers-140-add-4).

1) CODES-BARRES
J'ai effectivement rencontré quelques effets de bord semblables aux tiens dans la reconnaissance des codes-barres mais dans une moindre mesure car anticipant la 1.4 en début d'année, j'ai changé mes lecteurs code-barre pour des full compatible 2D, EAN, CIP etc.

Oui, ces lecteurs sont chers et pas indispensables.
Oui il y a de l'abus surtout qu'à l'achat, le lecteur lui-même PEUT lire les codes 2D mais ne le fait pas tant que l'on a pas acheté la mise à jour spéciale à xxx euros ............ par lecteur.

L'intérêt, c'est qu'il y a extrêmement peu de rejets de lecture de codes dans cette config, dû essentiellement au fait que ces lecteurs recents lisent tous les codes plus ou moins exotiques imprimés sur les conditionnements (dont les codes sandauz à espacements bizarres) donc quand un CIP ne passe pas, l'EAN passe, sinon la vignette ou sinon le code 2D. Notes qu'on peut faire la manip dans le désordre... On a eu à peu près 10 codes renvoyant sur le mauvais produit et 20 codes inconnus.

Et quand nous en avons un rejet complet de lecture de code, le code EAN est modifié immédiatement pour enregistrer le "résultat" lu par le lecteur sans se pré-occuper de quel code c'est, l'important étant que Premium reconnaisse le produit, son codage et son prix.
Le CIP13 sera toujours la référence commune mais quand il ne passe pas localement, ce n'est pas grave, un autre code est utilisé pour identifier le produit lors de la vente mais la facture vitale récupère uniquement le CIP13, le prix etc.

Du coup, le plus emm...dant, c'est l'absence de code-barre comme sur certains produits laino...

2) LECTEURS SESAM-VITALE NON COMPATIBLES
Attention aux lecteurs de type Twin10 REELLEMENT incompatibles avec la 1.4. Il générent alléatoirement des erreurs donc on s'est aperçu du problème 1 bon mois après migration car aucune erreur n'était survenue avant. Par contre quand l'erreur survient, tu perds ta facture - tant pis pour toi...

3) LISTES D'OPPOSITION DES CV
Ces listes sont censées être adressées tous les jours sauf ............... que ce n'est pas le cas. Et quand passe une semaine calendaire sans mise à jour des listes, une erreur survient sur tous les postes ! Pas grave mais emm...

[Liste non limitative à compléter]

Bonjour,

Quels sont ceux parmi vous qui ont déjà mis en place une version de leur logiciel compatible avec le cahier des charges 1.40 ?

Comment cette migration s'est elle passée ? Quels bugs avez rencontrés ? Quels effets de bord ?

J'ai réalisé cette migration la semaine dernière. La mise à jour n'a pas posé de problème en elle même. Par contre, j'ai eu plusieurs soucis après.

1) Des bugs : La lecture de l'étiquette de prix de certains médicaments remboursables n'était pas correcte, le logiciel ne reconnaissait pas le code barre et proposait de créer une nouvelle fiche. Difficile de savoir si cela vient d'un soucis logiciel, matériel ou extérieur à la solution informatique.

2) Des effets de bord : La mise à jour du logiciel modifie sa façon de lire les codes barre. Je n'ai pas eu de soucis à quelques rares exceptions avec les produits remboursables. Pour les autres, cela se corse. La responsabilité est partagée entre divers intervenants : Beaucoup de labos n'ont pas encore mis à jour le marquage de leurs produits. Premium considère arbitrairement qu'un code barre de 13 caractères est un CIP13. Quand on lit l'EAN13 d'un produit de para, le logiciel applique une règle inappropriée pour déduire l'identité du produit dont le code lu est inconnu. En effet, il considère que c'est OBLIGATOIREMENT un CIP13 et extrait donc le CIP7 de ce CIP 13. Il vous propose alors de créer un article qui était déjà référencé avant la migration, mais qu'il ne sait plus reconnaître. Tant que les mises à jours des bases sur lesquelles s'appuient nos systèmes n'auront pas été faites, ce sera le règne du réglage manuel, du moins si tous les logiciels adoptent le même principe de fonctionnement.

Quelles sont vos expériences pour ceux qui ont déjà la migration ?

Rémi