Sur base de votre feedback et des résultats obtenus durant les procédures de certification en cours, nous énumérons ici quelques "best practices" qui peuvent vous être utiles lors du développement :
- Afin de réduire au maximum les conflits de communication entre les systèmes de caisse et le FDM, il est recommandé que le système de caisse vérifie de manière régulière le statut du FDM. Il est surtout recommandé d'effectuer un request du statut du FDM et de l'identification FMD lorsque le système de caisse fait un restart, avant d'envoyer une request "hash & sign" .
- Le système de caisse ne peut envoyer un request "send PIN" ("P") qu'en réponse aux codes d'erreur prioritaires 202 ou 204
- Dans le Request "J" (journal), le champ 4 détermine la longueur de la donnée envoyée dans le champ 6. Si vous utilisez une longueur disponible maximale de 256 symboles hexadécimaux dans le champ 6, ce qui correspond à 128 databytes, la valeur du champ 4 est de 256. Si vous n'utilisez pas la longueur maximale du champ 6, donnez alors la longueur exacte en symboles hex (min. 2).
- Pour un protocole de série, le "best practice" est de n'envoyer le message suivant que lorsque le précédent a été entièrement traité, y compris tous les retries autorisés.
- Après leur personnalisation, les VSC's contiennent le FDM-id de l'appareil indiqué par l'assujetti-exploitant pour l'utilisation de la VSC. L'utilisation de la VSC personnalisée dans un autre FDM que celui pour lequel la carte a été initialisée n'est pas un facteur bloquant. Toutefois, un avertissement sera envoyé au FDM lors de toute utilisation. Dans la pratique, il n'est pas utile d'envoyer cet avertissement au système de caisse.
- Veillez à ce qu'en cas de request "P" (send pin code), tant le système de caisse que le fiscal data module vérifient la composition exacte de ce pin au niveau de la longueur, de la présence de blancs...
