Pourquoi est-ce que les caractères Unicode ne s’impriment pas correctement avec SAP ?

Les applications SAP existent depuis longtemps et les documents imprimés existent depuis plus longtemps encore. Au fil des ans, les technologies et les critères ont évolué afin de permettre l’impression dans des environnements SAP. Toutefois, des problèmes persistent, surtout dans des grandes entreprises d’envergure internationale.

Le standard Unicode est un système universel qui permet d’encoder et de présenter tous les caractères de n’importe quelle langue. A contrario, l’ancien système de codage de caractères internationaux pour le traitement de texte ne parvenait à présenter qu’un échantillon des symboles existants.

Par exemple, il existe une norme différente pour l’Europe occidentale (ISO-8859-1, ou CP1252) et pour l’Europe de l’est, l’alphabet cyrillique, etc. Outre ces normes appelées « simple octet » (qui peuvent supporter 225 caractères maximum), il existe également des normes à double octet pour les caractères asiatiques (par ex., GB2312) qui supportent plus de 60 000 symboles.

Unicode, en revanche, fournit différents codages pour afficher tous les caractères, les dénommés Unicode Transformation Formats, UTF-8. UTF-16 est utilisé en interne par l’environnement SAP, ce qui signifie que chaque caractère utilise deux octets de données. Pour des présentations Unicode dans des flux de données tels que les données d’impression, les fichiers XML et HTML, UTF-8 est souvent utilisé. C’est notamment une façon plus efficace d’afficher les symboles ASCII et les caractères européens spéciaux.

Parfait... Il existe donc de multiples façons de gérer des caractères imprimés. Mais alors quel est le rapport avec les problèmes d’impression des applications SAP ?

SAP et Unicode

SAP a officiellement introduit le support d’Unicode dans SAP R/3 version 4.7C. Ce faisant, une solution élégante était proposé pour gérer la saisie et le stockage des données de tous les caractères utilisés dans les langues du monde entier. Mais lorsqu’il s’agit d’imprimer des documents avec Unicode, surtout avec les caractères asiatiques, des problèmes peuvent se poser. Deux des problèmes les plus épineux concernent la prise en charge de périphérique et les pilotes de sortie.

Le hic, c'est que la plupart des périphériques ne sont pas conçus pour imprimer ces caractères à double octet. Si vous envoyez un document avec des caractères japonais à une imprimante lambda, par exemple, le pilote d'impression SAP remplacera les symboles non supportés par « # ».

En outre, SAP ne fournit que quelques types de périphériques (pilotes) pour des imprimantes spéciales qui supportent les caractères asiatiques ou cyrilliques. Généralement, ces pilotes ne supportent que certaines pages de code. Entre autres, cela signifie qu'il vous faudra créer plus d’un « device type » pour chaque imprimante physique.

Bien évidemment, il existe des imprimantes qui supportent des polices de caractères asiatiques. Toutefois, celles-ci ne sont facilement disponibles qu’en Asie. Et habituellement, elles ne supportent que l’impression de pages de code à double octet. Peu d’imprimantes sont capables de gérer Unicode sous la forme UTF-8. En plus de la question du support d’Unicode, il y a également celle de l’incorporation de polices de caractères spécifiques à SAP, comme Andale.

Ce problème représente un défi de taille pour l’utilisateur. Si vous souhaitez envoyer Unicode directement depuis SAP, vous êtes limité à un petit nombre de périphériques de sortie et/ou de fournisseurs de matériel informatique. Vous êtes assujetti à une gamme restreinte de modèles d’imprimantes et de fabricants, ce qui rend difficile l’utilisation de périphériques plus rentables et avec plus d’options. Même la mise à niveau des imprimantes actuelles avec des modules spéciaux pour supporter l’impression Unicode s’avère problématique, car cela vous rend dépendant à la fois du fabricant et du fournisseur des périphériques associés.

Les pilotes de sortie

Il y a plusieurs éléments à prendre en compte du côté SAP de l’équation.

Pour chaque imprimante capable de supporter Unicode que vous voulez utiliser, vous avez besoin d’une définition des « device type » disponibles pour les différentes versions de SAP. Faute de quoi, ces imprimantes n’auront que peu d’utilité. Il en va de même pour les imprimantes sur lesquelles vous avez installé des modules DIMM pour permettre l’impression Unicode. S’il n’y a plus de définitions disponibles pour les « device type » pour votre suite SAP ERP, investir dans les DIMM est inutile.

Outre la disponibilité des ressources, il ne faut pas oublier l’effort administratif nécessaire pour installer, configurer, tester et distribuer les pilotes de périphériques dans le paysage SAP. Ce n’est pas tâche aisée étant donné le nombre de variables.

La solution

SAP propose plusieurs de ses solutions à ce dilemme. Pour commencer, vous pouvez utiliser le dispositif SAPWIN et imprimer les données Unicode via Windows. Mais il est évident que cela vous rend dépendant des fonctionnalités d’impression de Windows. Pour les plus récentes versions de SAP, il est possible d’utiliser SAP UPE (Unicode Priting Enhancement, « amélioration de l’impression Unicode », disponible sur SAP NetWeaver 7.02) ou SAP Interactive forms d’Adobe (SAP ADS, disponible depuis la version SAP NetWeaver 2004). Les deux rendent l’impression Unicode possible. Cependant, le problème de support des différents « device type » dans SAP demeure. De plus, ces solutions ne sont pas disponibles pour toutes les versions de SAP encore en usage. SAP ADS n'est pas aussi répandu que SAPScript et SmartForms, mais peut être pris en considération.

Pour résoudre le problème de l’impression Unicode, LRS propose une solution techniquement élégante, conçue en gardant à l’esprit l’indépendance de la plateforme et la soutenabilité future. LRS Transforms rend possible la production de caractères Unicode grâce à un logiciel plutôt qu’avec du matériel informatique. Cela vous permet de supporter l’impression SAP et Unicode sur n’importe quels périphériques de sortie venant de fabricants différents. Le matériel spécifique et les mises à niveau SAP deviennent inutiles.

Cette solution présente aussi un autre avantage : vous n’avez besoin que d’un seul « device type » : SAPGOFU. Ce dispositif ne se contente pas seulement de simplifier la gestion des imprimantes dans votre environnement SAP, mais il réduit également la charge sur votre serveur SAP qui sert à créer des tâches d’impression. Le module LRS Transforms transfère les impressions au serveur VPSX. Résultat ? Une meilleure optimisation des ressources du système SAP et une réduction de l’effort administratif lié à l’impression.

Lorsqu’il s’agit d’imprimer à partir de vos applications SAP, des options sont disponibles. En revanche, toutes ne se valent pas. Si vous pesez le pour et le contre de chaque méthode, n’hésitez pas à contacter LRS pour obtenir des conseils. Nous nous ferons un plaisir de vous aider.