Documentation technique et fonctionnelle KWISATZ

Les plateformes de fidélité

KWISATZ peut communiquer avec une plateforme de fidélisation externe afin de centraliser les clients, les points, les cagnottes et les bons dans un environnement multi-magasins. La documentation fournie décrit principalement les interfaces ADELYA et ZEROSIX.

Télécharger cette fiche en PDF
Fiche : FID-EXT-001 Module : Vente directe / Fidélité externe Public : technicien Risque : critique Catégorie : Fidélité, cartes, abonnements et campagnes clientsMise à jour : 6 août 2026

Réponse directe

Configurez uniquement l’interface réellement souscrite : ADELYA ou ZEROSIX. Faites renseigner les accès par un technicien, programmez les fonctions documentées — 167 — ADELYA — Créer une carte ou 212 — Fonction ZEROSIX — puis testez un client, un ticket encaissé et l’utilisation d’un avantage. Ne mettez en production qu’après contrôle du solde sur la plateforme.
Ne saisissez jamais une clé API, un token, un mot de passe ou une URL de production à partir d’un exemple public. Les identifiants doivent être fournis par la plateforme, protégés et testés sur une caisse pilote.

Conseil pour les paramètres et configurations

Conseil technicien : ne saisissez pas seul les secrets de production et ne recopiez jamais les paramètres d’un autre commerçant. Faites qualifier la plateforme réellement utilisée, le programme souscrit, les caisses concernées, les modes de règlement, les articles techniques et la stratégie anti-doublon avant toute activation.

1. Repères de version

Les références de version ci-dessous sont conservées comme repères documentaires. Les menus, options et comportements doivent être contrôlés sur la version et la sérialisation réellement installées ; une évolution plus récente peut avoir modifié le fonctionnement.

2. Licence et disponibilité

La dépendance de licence mentionnée dans ce document provient des sources. Sa disponibilité peut varier selon la version, la sérialisation, le partenaire ou l’installation ; faites-la valider techniquement avant de modifier l’environnement.

3. Distinguer abonnements et fidélité

Les abonnements correspondent à des prestations disponibles et consommables dans les tickets lorsque le client est sélectionné. Ils ne doivent pas être confondus avec les points ou passages de fidélité. Un devis, une facture, un rendez-vous ou un mouvement financier ne constitue pas, à lui seul, une consommation d’abonnement.

Évitez le double avantage : ne cumulez pas correction du ticket, ajout manuel et recalcul de fidélité. Lors d’un oubli de carte, corrigez le rattachement du ticket sans créditer manuellement une seconde fois.

4. Distinguer KWISATZ des opérations externes

Un enregistrement dans KWISATZ ne prouve pas automatiquement qu’une opération a été exécutée dans un système externe : débit ou remboursement TPE, mouvement physique d’espèces, envoi de SMS ou d’e-mail, ou action réalisée sur une plateforme.

5. Fidélité locale ou fidélité externe

Conseil technicien : toute modification d’une plateforme, d’une URL, d’un token, d’une clé API, d’un mode de règlement, d’une catégorie client, d’une touche 167 ou 212, d’un programme Cycle/Cagnotte ou d’une architecture multi-caisses doit être réalisée ou validée avec l’aide d’un technicien KWISATZ et du prestataire. Sauvegardez le dossier et testez sur une caisse pilote.
Mode Source de référence Fonctionnement
Fidélité KWISATZ Base clients et paramètres du dossier KWISATZ. Les règles du dossier KWISATZ calculent les avantages locaux.
Plateforme externe Compte cloud du prestataire. KWISATZ échange avec la plateforme selon l’interface activée ; la plateforme calcule la situation qu’elle gère.
Ticket dématérialisé Service d’envoi ou d’archivage du ticket. Service distinct ; sa présence ne prouve pas l’existence d’une cagnotte ou d’un programme de fidélité complet.
N’activez pas deux moteurs pour le même avantage sans procédure validée. Un calcul local et un calcul externe appliqués au même ticket peuvent produire un double crédit ou une reprise incohérente.

6. Prérequis

Conseil technicien : toute modification d’une plateforme, d’une URL, d’un token, d’une clé API, d’un mode de règlement, d’une catégorie client, d’une touche 167 ou 212, d’un programme Cycle/Cagnotte ou d’une architecture multi-caisses doit être réalisée ou validée avec l’aide d’un technicien KWISATZ et du prestataire. Sauvegardez le dossier et testez sur une caisse pilote.
  • compte opérationnel auprès du prestataire ;
  • programme commercial défini et documenté ;
  • option KWISATZ active sur les caisses qui communiquent réellement ;
  • version compatible avec l’interface et les fonctions utilisées ;
  • connexion Internet stable et sécurisée ;
  • URL et secret fournis pour le compte du commerçant ;
  • modes de règlement, catégories et articles techniques contrôlés ;
  • touches de caisse programmées et testées ;
  • client et ticket de recette identifiables ;
  • procédure anti-doublon et règles de protection des données.
Pour une installation multi-caisses ou autonome, faites déterminer quelles licences communiquent réellement avec la plateforme. Ne généralisez pas l’option à partir d’un seul poste de test.

7. Comprendre le flux d’une transaction

Conseil technicien : toute modification d’une plateforme, d’une URL, d’un token, d’une clé API, d’un mode de règlement, d’une catégorie client, d’une touche 167 ou 212, d’un programme Cycle/Cagnotte ou d’une architecture multi-caisses doit être réalisée ou validée avec l’aide d’un technicien KWISATZ et du prestataire. Sauvegardez le dossier et testez sur une caisse pilote.
  1. Le client présente sa carte, son téléphone ou son identifiant.
  2. KWISATZ interroge la plateforme.
  3. La fiche locale est retrouvée, associée, créée ou actualisée selon le cas.
  4. L’opérateur saisit le ticket normalement.
  5. Un avantage peut être proposé au moment du Total.
  6. Le ticket est encaissé.
  7. KWISATZ transmet la transaction à la plateforme.
  8. La plateforme recalcule les points, vouchers ou la cagnotte.
  9. La nouvelle situation est renvoyée lorsque l’échange aboutit.
  10. Les informations disponibles peuvent être affichées ou imprimées selon la version.
Ne concluez pas à une mise à jour réussie avant l’encaissement complet. Pour ZEROSIX, la transmission et le recalcul documentés interviennent après validation du ticket.

8. Configurer ADELYA

Conseil technicien : les paramètres ADELYA historiques contiennent des secrets. Toute intervention dans PREFERENCES.ini doit être sauvegardée, tracée et testée.

L’interface ADELYA historique utilise des paramètres techniques dans la section COMMUN de PREFERENCES.ini. Leur présence et leur nom doivent être contrôlés sur la version installée.

Paramètre Rôle
FIDELITE_ADELYA_ACTIVEE Active ou désactive l’interface.
FIDELITE_ADELYA_URL_BASE Adresse du service fournie et validée pour le compte.
FIDELITE_ADELYA_URL_APIKEY Clé API secrète du compte.
FIDELITE_ADELYA_URL_USER Identifiant technique lorsque la configuration l’utilise.
FIDELITE_ADELYA_URL_PASSWORD Mot de passe technique lorsque la configuration l’utilise.
FIDELITE_ADELYA_RADICAL_CARTE_01 Radical de carte défini pour le programme.
FIDELITE_ADELYA_RADICAL_CARTE_02 Radical de carte défini pour le programme.
FIDELITE_ADELYA_CODE_REGLEMENT Code du règlement utilisé pour les opérations de carte.
FIDELITE_ADELYA_CODE_CATEGORIE_CLIENT Catégorie appliquée aux fiches associées selon la configuration.
Repère de diagnostic : PREFERENCES.ini. Ce repère interne ne doit pas être modifié directement. Faites analyser et valider le réglage par un technicien KWISATZ après sauvegarde et relevé de la configuration.

9. Configurer les fonctions ADELYA

Conseil technicien : toute modification d’une plateforme, d’une URL, d’un token, d’une clé API, d’un mode de règlement, d’une catégorie client, d’une touche 167 ou 212, d’un programme Cycle/Cagnotte ou d’une architecture multi-caisses doit être réalisée ou validée avec l’aide d’un technicien KWISATZ et du prestataire. Sauvegardez le dossier et testez sur une caisse pilote.

Ajoutez au clavier tactile la fonction 167 — ADELYA — Créer une carte.

La procédure de création documentée demande :

  • la lecture ou la saisie du code-barres de la carte ;
  • le nom du client ;
  • éventuellement son adresse e-mail ;
  • la validation de l’envoi vers la plateforme.
La documentation historique décrit une carte EAN13 et une extraction d’un code client sur certaines positions. Vérifiez le format réel du programme avant de créer ou modifier une règle de lecture.

10. Utiliser une carte ADELYA

Conseil technicien : testez séparément l’identification, la recharge, le paiement partiel et le rendu monnaie avec le règlement ADELYA.

Identifier le client

  1. Scannez la carte dans la vente directe.
  2. KWISATZ reconnaît son radical.
  3. La plateforme est interrogée.
  4. Les informations administratives et le solde sont récupérés.
  5. La fiche locale est actualisée avec les données de la plateforme.
  6. La catégorie client ADELYA est appliquée selon la configuration.

Lorsque la carte n’est pas lisible, utilisez uniquement la recherche ou la procédure de secours réellement configurée.

Recharger la carte

La documentation prévoit les articles techniques suivants :

  • CARTE025 ;
  • CARTE050 ;
  • CARTE100.

La documentation historique associe ces articles techniques à des montants de recharge. Testez chaque code et sa valeur avant utilisation.

Payer avec la carte

  1. Sélectionnez le client ADELYA.
  2. Saisissez les produits.
  3. Utilisez le mode de règlement configuré pour ADELYA.
  4. Saisissez le montant à débiter.
  5. Finalisez le ticket.
  6. Contrôlez le nouveau solde.
Le rendu monnaie et les opérations partielles doivent être testés avec le règlement ADELYA configuré. Un mouvement mal paramétré peut modifier le solde de la carte dans le sens opposé à celui attendu.

11. Configurer ZEROSIX

Conseil technicien : faites contrôler l’URL, le token, le programme, le règlement voucher et la temporisation. Ne recopiez pas la configuration d’un autre compte.

Dans les versions documentées, la configuration se trouve dans les préférences de Vente directe, section Plateforme ZEROSIX — Fidélité cloud. Le chemin exact doit être vérifié sur la version installée.

Zone Utilisation
Activer Active la fidélité ZEROSIX.
URL Adresse API fournie pour le compte du commerçant.
Token Secret du compte à protéger et à tester.
Type de programme Cycle ou Cagnotte selon le programme réellement souscrit.
Bon voucher — mode de règlement associé Règlement utilisé pour comptabiliser le bon.
Reprise voucher par vente négative Mode alternatif de reprise à valider avec la version et la comptabilité.
Recherche client — nombre minimum de caractères Limite les recherches trop larges ; la documentation historique indique 3 par défaut.
Connexion — Timeout Temporisation de connexion ; la documentation historique indique 10 secondes par défaut.
Ne saisissez pas le token dans la zone URL, ni l’URL dans la zone Token. Cette inversion est une cause documentée d’échec lors de la création d’un contact.

12. Choisir le programme ZEROSIX

Conseil technicien : toute modification d’une plateforme, d’une URL, d’un token, d’une clé API, d’un mode de règlement, d’une catégorie client, d’une touche 167 ou 212, d’un programme Cycle/Cagnotte ou d’une architecture multi-caisses doit être réalisée ou validée avec l’aide d’un technicien KWISATZ et du prestataire. Sauvegardez le dossier et testez sur une caisse pilote.
Programme Accumulation Utilisation
Cycle Le programme cumule des points et peut générer des vouchers selon ses règles. Utilisation d’un bon disponible au moment prévu par la plateforme.
Cagnotte Le programme gère une valeur disponible selon ses propres règles. Utilisation totale ou partielle lorsque la version KWISATZ et le compte le permettent.
Le type choisi dans KWISATZ doit correspondre au programme réellement souscrit sur le compte ZEROSIX. Un mauvais choix peut produire un affichage ou une reprise incohérents.

13. Configurer les fonctions ZEROSIX

Conseil technicien : toute modification d’une plateforme, d’une URL, d’un token, d’une clé API, d’un mode de règlement, d’une catégorie client, d’une touche 167 ou 212, d’un programme Cycle/Cagnotte ou d’une architecture multi-caisses doit être réalisée ou validée avec l’aide d’un technicien KWISATZ et du prestataire. Sauvegardez le dossier et testez sur une caisse pilote.

Ajoutez la fonction 212 — Fonction ZEROSIX au clavier tactile.

Paramètre Fonction
-A1 Ouvre les opérations de gestion ou de recherche documentées.
-A2 Ouvre la liste des vouchers utilisables selon la configuration.
Les fonctions visibles peuvent évoluer selon la version et le programme Cycle ou Cagnotte. Testez le clavier avec la version réellement installée.

14. Rechercher et associer un client ZEROSIX

Conseil technicien : recherchez le client avant toute création. Le champ CLOUD_ID est interne et ne doit pas être modifié directement.

La recherche peut porter sur le début du nom ou du numéro de téléphone. Le nombre minimum de caractères évite de renvoyer une liste trop importante.

Client déjà associé

La liaison utilise un identifiant cloud mémorisé dans la fiche. CLOUD_ID est un champ interne utile au diagnostic ; ne le modifiez pas directement.

Client présent uniquement chez ZEROSIX

La sélection peut créer une fiche KWISATZ locale associée à l’identifiant cloud.

Client présent dans les deux systèmes mais non associé

Utilisez la fonction d’association afin d’éviter une nouvelle fiche.

Client présent uniquement dans KWISATZ

Utilisez la procédure prévue pour créer le contact sur la plateforme puis contrôlez l’association.

Client nouveau dans les deux systèmes

Créez la fiche depuis la fenêtre ZEROSIX lorsque la procédure le prévoit, puis contrôlez les deux fiches.

Lors d’une reprise de base, utilisez le format de téléphone demandé par le prestataire et validé pour le compte. La règle historique 06/07 sans séparateur ne doit pas être généralisée sans test.
Ne créez pas une nouvelle fiche avant d’avoir effectué une recherche sur la plateforme. L’association après création est possible, mais le risque de doublon est plus élevé.

15. Saisir et transmettre un ticket ZEROSIX

Conseil technicien : après une erreur de transmission, vérifiez la plateforme et les journaux avant de relancer ou recréer le ticket.
  1. Recherchez et sélectionnez le client.
  2. Vérifiez son nom et sa situation fidélité.
  3. Saisissez le ticket normalement.
  4. Au Total, contrôlez les vouchers ou la cagnotte proposés.
  5. Utilisez un avantage si le client le souhaite.
  6. Encaissez le solde restant.
  7. Finalisez le ticket.
  8. KWISATZ tente de transmettre la transaction à ZEROSIX.
  9. La plateforme recalcule la situation lorsque la transmission aboutit.
  10. Contrôlez le retour, le solde sur la plateforme et les informations disponibles.
Pour le diagnostic, relevez le numéro du ticket, la caisse, le client, l’identifiant de transaction disponible et l’identifiant cloud. Ne modifiez pas les champs internes.

16. Utiliser les vouchers et la cagnotte

Conseil technicien : testez les vouchers et la cagnotte sur un ticket maîtrisé. Contrôlez le règlement, le financier et le solde sur la plateforme.

Voucher — Programme Cycle

ZEROSIX peut transformer automatiquement les points en bons lorsqu’un seuil est atteint. À l’appel du Total, KWISATZ propose les bons disponibles.

  1. Ouvrez la liste des vouchers.
  2. Sélectionnez le bon voulu.
  3. Validez son utilisation.
  4. Contrôlez sa reprise comme règlement ou vente négative selon la configuration.
  5. Vérifiez le solde du ticket et la disparition du bon utilisé.

Cagnotte — Programme Cagnotte

Le suivi de développement documente, à partir de la branche 3.56, l’utilisation directe de la cagnotte sur les versions compatibles. Vérifiez la révision installée avant de l’annoncer en production.

  1. Vérifiez le montant disponible.
  2. Saisissez le montant à utiliser.
  3. Contrôlez qu’il ne dépasse ni le solde du ticket ni la cagnotte.
  4. Encaissez le reste par un autre règlement si nécessaire.
  5. Contrôlez le nouveau solde renvoyé par ZEROSIX.
Ne relancez pas manuellement une consommation d’avantage après une erreur sans vérifier son état sur la plateforme. La première tentative peut avoir été acceptée même si la réponse n’est pas revenue à la caisse.

17. Architecture multi-caisses et multi-magasins

Conseil technicien : faites recenser les licences, caisses et comptes qui communiquent réellement avec la plateforme avant le déploiement.

Une plateforme externe peut centraliser la situation fidélité pour plusieurs magasins. Chaque caisse concernée communique avec le compte commun selon l’architecture et la licence validées.

  1. Recensez les caisses qui recherchent des clients cloud.
  2. Recensez celles qui cumulent ou consomment la fidélité.
  3. Activez le module sur les licences concernées.
  4. N’équipez pas inutilement un Back-Office sans rôle d’encaissement.
  5. Testez un même client sur deux caisses.
  6. Vérifiez la mise à jour du solde après chaque transaction.
Chaque caisse autonome qui communique directement avec ZEROSIX peut nécessiter l’option correspondante. Faites valider les licences et le rôle du Back-Office dans l’architecture réelle.

18. Promotions, familles et exclusions

Conseil technicien : toute modification d’une plateforme, d’une URL, d’un token, d’une clé API, d’un mode de règlement, d’une catégorie client, d’une touche 167 ou 212, d’un programme Cycle/Cagnotte ou d’une architecture multi-caisses doit être réalisée ou validée avec l’aide d’un technicien KWISATZ et du prestataire. Sauvegardez le dossier et testez sur une caisse pilote.

Les règles de points, exclusions et promotions dépendent du programme configuré sur la plateforme. KWISATZ transmet les informations prévues par l’interface et la version.

  • contrôlez les codes articles transmis ;
  • contrôlez les familles ou catégories utilisées pour les exclusions ;
  • testez une ligne en promotion et une ligne hors promotion ;
  • vérifiez le ticket reçu sur la plateforme ;
  • comparez les points calculés avec la règle attendue ;
  • utilisez une version récente avant d’analyser une incohérence historique.
Le support documente l’utilisation du code famille comme information de catégorie dans certains échanges ZEROSIX. Contrôlez la version et le détail reçu par la plateforme avant d’attribuer une anomalie à la famille.

19. Sécurité et données clients

Conseil technicien : toute modification d’une plateforme, d’une URL, d’un token, d’une clé API, d’un mode de règlement, d’une catégorie client, d’une touche 167 ou 212, d’un programme Cycle/Cagnotte ou d’une architecture multi-caisses doit être réalisée ou validée avec l’aide d’un technicien KWISATZ et du prestataire. Sauvegardez le dossier et testez sur une caisse pilote.
  • protéger les tokens, clés API et mots de passe ;
  • masquer les secrets dans les captures et journaux transmis ;
  • limiter les droits sur PREFERENCES.ini ;
  • utiliser des connexions chiffrées fournies par la plateforme ;
  • ne transmettre que les données nécessaires au programme ;
  • documenter la plateforme comme destinataire ou sous-traitant selon le contrat ;
  • informer le client de l’utilisation de ses données et respecter ses choix ;
  • prévoir une procédure d’exercice des droits et de suppression ;
  • ne pas partager de données réelles dans un environnement de démonstration.
Conseil données personnelles : le commerçant doit définir les données transmises, les finalités, les durées, les droits des personnes et les responsabilités contractuelles avec le prestataire. Le paramétrage technique ne remplace pas cette validation.

20. Recette avant mise en production

Conseil technicien : toute modification d’une plateforme, d’une URL, d’un token, d’une clé API, d’un mode de règlement, d’une catégorie client, d’une touche 167 ou 212, d’un programme Cycle/Cagnotte ou d’une architecture multi-caisses doit être réalisée ou validée avec l’aide d’un technicien KWISATZ et du prestataire. Sauvegardez le dossier et testez sur une caisse pilote.
  1. Tester l’accès API depuis chaque caisse pilote.
  2. Rechercher un client existant sur la plateforme.
  3. Créer un client nouveau.
  4. Associer deux fiches existantes.
  5. Vérifier le champ CLOUD_ID.
  6. Réaliser un ticket sans avantage.
  7. Contrôler son apparition sur la plateforme.
  8. Contrôler les points ou la cagnotte après encaissement.
  9. Tester un voucher ou un paiement par cagnotte.
  10. Tester un règlement partiel.
  11. Tester une promotion et une famille exclue.
  12. Tester une indisponibilité simulée sur une caisse pilote sans perturber la production.
  13. Vérifier l’état de la première tentative avant toute nouvelle transmission.
  14. Contrôler le financier, le ticket imprimé et le journal de la plateforme.
L’interface est validée lorsque chaque client est associé sans doublon, chaque ticket encaissé est transmis une seule fois et le solde, les points, vouchers ou la cagnotte correspondent dans KWISATZ et sur la plateforme.

21. Diagnostic rapide

Conseil technicien : relevez la version, la caisse, le ticket, le client, le programme et les identifiants disponibles avant toute modification.
La recherche ZEROSIX ne contacte pas la plateforme
Contrôlez l’activation, l’URL, le token, la connexion, la licence et la version. Masquez le secret dans les captures.
Erreur lors de l’appel à « create contact »
Contrôlez notamment que l’URL et le token ne sont pas inversés. Recherchez d’abord le client avant de tenter une nouvelle création.
La recherche renvoie trop de clients
Augmentez le nombre minimum de caractères dans les préférences ZEROSIX. La valeur historique par défaut est 3.
Le client est dupliqué dans KWISATZ
Contrôlez l’association cloud et utilisez la procédure d’association. Ne modifiez pas directement le champ CLOUD_ID.
Le ticket n’apparaît pas sur ZEROSIX
Vérifiez l’encaissement, relevez les identifiants disponibles, contrôlez la connexion et les journaux. Ne recréez pas le ticket avant de connaître l’état de la première transmission.
Le ticket apparaît deux fois sur la plateforme
Comparez les identifiants de transaction, la date, la caisse et le client. Sans logs API et ticket source, ne concluez pas à un doublon KWISATZ.
Les points sont absents sur un produit en promotion
Contrôlez la règle ZEROSIX, la famille envoyée, l’exclusion promotionnelle et le détail des lignes reçues par la plateforme.
Le voucher n’est pas proposé au Total
Vérifiez le programme Cycle, les bons disponibles, la fonction 212 -A2 et le règlement associé.
La cagnotte n’est pas utilisable directement
Vérifiez le programme Cagnotte, la version 3.56 ou ultérieure réellement validée et la configuration du compte. Le développement de cette fonction a évolué selon les révisions.
La carte ADELYA n’est pas reconnue
Vérifiez les radicaux, la qualité du code-barres, l’activation de l’interface et la connexion aux services ADELYA.
Le solde ADELYA ne change pas après une recharge
Vérifiez le code exact de l’article technique, l’encaissement complet, le client sélectionné et la réponse de la plateforme.

22. Liste de contrôle de mise en service

Conseil technicien : toute modification d’une plateforme, d’une URL, d’un token, d’une clé API, d’un mode de règlement, d’une catégorie client, d’une touche 167 ou 212, d’un programme Cycle/Cagnotte ou d’une architecture multi-caisses doit être réalisée ou validée avec l’aide d’un technicien KWISATZ et du prestataire. Sauvegardez le dossier et testez sur une caisse pilote.
  • Le compte du prestataire est opérationnel.
  • La licence est active sur chaque caisse concernée.
  • L’URL et le secret API sont validés.
  • Le programme Cycle ou Cagnotte est correct.
  • Les modes de règlement sont configurés.
  • Les touches 167 ou 212 sont testées.
  • Les clients existants sont recherchés avant création.
  • Les associations CLOUD_ID sont contrôlées.
  • Un ticket est transmis une seule fois.
  • Les points, vouchers ou soldes concordent.
  • Les promotions et exclusions sont testées.
  • Les secrets et données clients sont protégés.

23. Évolutions ZEROSIX documentées à vérifier

Conseil technicien : toute modification d’une plateforme, d’une URL, d’un token, d’une clé API, d’un mode de règlement, d’une catégorie client, d’une touche 167 ou 212, d’un programme Cycle/Cagnotte ou d’une architecture multi-caisses doit être réalisée ou validée avec l’aide d’un technicien KWISATZ et du prestataire. Sauvegardez le dossier et testez sur une caisse pilote.
Évolution Information
Programme Cycle ou CagnotteChoix documenté dans la branche 3.56.
Recherche clientNombre minimum de caractères ajouté dans les préférences.
Temporisation de connexionRéglage documenté, avec 10 secondes comme valeur historique par défaut.
Cagnotte directeDéveloppement et tests documentés en juin 2025 dans la branche 3.56.
Promotions et identifiants de ticketCorrectifs successifs documentés ; relever la version exacte pour tout diagnostic.

24. Sources documentaires

  • Tutoriel KWISATZ — paramétrage et utilisation des interfaces ADELYA et ZEROSIX.
  • Tutoriel KWISATZ — création, recherche et association des clients ZEROSIX.
  • Fonctions de caisse KWISATZ — 167 ADELYA et 212 ZEROSIX.
  • Suivi de développement KWISATZ — programme Cycle/Cagnotte, temporisation et cagnotte directe.
  • Base support KWISATZ — URL/token, association cloud, identifiants de ticket, promotions et licences multi-caisses.