Basculer depuis Événement¶

AdministrateurSéances

Vous vendez vos spectacles ou vos visites guidées avec le module Événement natif d'Odoo depuis quelques saisons, et vous venez d'installer la Billetterie Moka pour profiter de ses séances, de son contrôle d'accès et de son suivi pensé pour le tourisme. Reste une question : que faire de tous les programmes, billets et inscriptions déjà enregistrés côté Événement ? Les ressaisir à la main n'est plus envisageable au-delà de quelques dizaines d'inscriptions.

Un assistant de migration reprend ce travail à votre place : il lit vos données Événement et crée automatiquement les programmes, séances, billets et visiteurs équivalents côté Billetterie, sans jamais toucher à vos données d'origine. Vous le retrouvez dans Billetterie > Configuration > Event to Ticketing Migration.

Testez toujours la bascule complète sur une base de test avant la production

Cette opération touche à la fois vos données et votre vente en ligne : mal enchaînée, elle peut faire vendre le même spectacle ou la même visite des deux côtés en même temps, ou provoquer des effets de bord au point de vente comme sur le site. Avant de vous lancer en production :

Rejouez d'abord la bascule complète — Détection, Aperçu, Migration, Résultat, puis dépublication côté Événement — sur une copie de votre base, pour vérifier que tout se déroule comme prévu chez vous.
Respectez ensuite strictement l'ordre décrit dans ce tutoriel. Chaque étape protège la suivante ; l'inverser expose à de mauvaises surprises, pour vos clients comme pour votre trésorerie.

Prérequis

Avant d'aller plus loin, assurez-vous que :

Le module event_to_ticketing_migration est installé (menu Apps).
Les modules Billetterie correspondant à vos modules Événement installés existent déjà, ou vous acceptez que l'assistant les installe pour vous à l'étape Aperçu.
Une sauvegarde récente de votre base existe.
Vous avez convenu avec votre équipe d'une date et d'un horaire de bascule : hors des horaires d'ouverture au public, sans vente en cours au point de vente ni en ligne, et surtout jamais juste avant un événement important — pour ne perturber ni vos ventes ni vos visiteurs.

Ce que l'assistant reprend pour vous¶

Avant de se lancer, autant savoir ce qui part et ce qui reste. L'assistant lit vos données Événement et recrée leur équivalent côté Billetterie, sans rien vous demander de ressaisir :

Vos événements deviennent des programmes (avec description, images et référencement).
Vos types de billets deviennent des billets et leurs articles de vente.
Vos séances (si vous utilisiez le module Séances d'Événement) deviennent des séances Billetterie.
Vos inscriptions deviennent des visiteurs, avec leurs réponses aux questions posées à l'achat.
Vos étiquettes et vos visuels de couverture suivent le mouvement.
Les commandes de vente et tickets de caisse déjà encaissés sont reliés automatiquement à ces nouveaux enregistrements, pour que l'historique reste consultable après la bascule.

À savoir

L'assistant est additif : il ne dépublie ni n'archive jamais vos événements d'origine, et il reconnaît ce qu'il a déjà migré si vous le relancez — pas de risque de doublons en le relançant plusieurs fois.

Le billet déjà imprimé ou envoyé par e-mail change de QR code

Chaque visiteur migré reçoit un nouveau code interne, donc un nouveau QR code — généré par la Billetterie exactement comme pour un billet créé directement chez vous. L'ancien code-barre Événement n'est pas repris tel quel comme identifiant du billet : un billet déjà imprimé ou envoyé par e-mail avant la bascule affiche donc un code qui ne sera plus reconnu tel quel au scan une fois la migration faite.

Cet ancien code est bien conservé automatiquement, en archive, dans le champ Code-barre original du visiteur migré — que le module ci-dessous soit installé ou non au moment de la bascule. Mais il ne redevient reconnaissable au scan (caisse ou application mobile) que si le module ticketing_external_barcode est installé ; sans lui, ce champ reste renseigné mais sans aucun effet. Si vos visiteurs ont déjà leur billet en main avant la bascule, installez ce module pour éviter d'avoir à réimprimer ou à renvoyer les billets déjà émis.

Avant de lancer la bascule¶

Une migration se prépare comme un inventaire : on regarde ce qu'il y a à déplacer avant de commencer à porter les cartons. Ouvrez Billetterie > Configuration > Event to Ticketing Migration.

Le wizard s'ouvre sur l'étape Detection : cliquez sur Detect pour scanner vos modules Événement installés et compter les enregistrements à migrer.

Vous passez alors à l'étape Preview, qui donne une vue d'ensemble avant d'engager quoi que ce soit : la correspondance entre vos modules Événement et leurs équivalents Billetterie, un contrôle de cohérence du schéma de votre base (Schema Check), les volumes à migrer (programmes, séances, billets, inscriptions, questions) et un signalement des éventuels tickets orphelins (des billets sans événement rattaché, généralement issus d'anciennes suppressions). S'il manque encore des modules Billetterie côté cible, un bouton Install Additional Modules apparaît pour les installer en un clic avant de continuer.

Avant de continuer, prenez le temps de :

Vérifier que Schema Check affiche bien Database schema is coherent — si ce n'est pas le cas, mettez à jour les modules listés (odoo -u) avant d'aller plus loin.
Noter les volumes annoncés (Records to Migrate) et les comparer à ce que vous attendez de votre activité — un chiffre très inférieur à ce que vous imaginiez peut signaler un module Événement non détecté.
Lire l'encart Orphan Tickets s'il apparaît : il indique combien de billets orphelins sont récupérables automatiquement (via un participant), combien restent ambigus (il vous avertira dessus) et combien seront ignorés faute de tout point de rattachement.
Vous assurer qu'une sauvegarde récente de la base existe, et retenir un créneau à faible trafic pour l'étape suivante.

Lancer la migration¶

Une fois ces vérifications faites, vous pouvez lancer la migration proprement dite — idéalement pendant le créneau calme repéré à l'étape précédente.

Cliquez sur Migrate Data.
Une confirmation récapitule ce que l'opération va créer : programmes, séances, produits et visiteurs à partir de vos données Événement.
Confirmez avec Ok. Pour une très grosse base, cochez au préalable Commit in batches : la migration valide alors ses écritures par lots de quelques centaines d'enregistrements plutôt qu'en une seule transaction, ce qui encaisse mieux un très gros volume — au prix de ne plus pouvoir tout annuler d'un bloc en cas d'interruption (un nouveau lancement reprend proprement là où elle s'est arrêtée, sans dupliquer ce qui est déjà passé).

À la fin, l'étape Done affiche un bilan chiffré (programmes créés, billets, visiteurs, questions migrées, avertissements…).

Lire le journal et le rapport d'écart¶

Sous ce bilan, le journal détaille chaque enregistrement traité, puis se termine par un rapport d'écart (« gap report ») : un tableau qui compare, ligne par ligne, ce qui existait côté Événement à ce qui a été recréé côté Billetterie, avec une colonne d'explication dès qu'un écart est normal.

Un écart n'est donc pas automatiquement un défaut — par exemple, ci-dessus, Sessions affiche +2 : c'est normal, un événement à date unique génère automatiquement une séance équivalente. En revanche, tout écart sans explication à côté mérite d'être regardé de plus près avant de continuer.

Rejouer une action ciblée si besoin¶

Si le gap report signale un point précis à corriger, inutile de relancer toute la migration : l'étape Preview propose des actions de réparation qui ne rejouent qu'un seul volet, sur les enregistrements déjà migrés :

Gap Report — recalcule le rapport d'écart sans rien modifier, utile pour vérifier l'état d'une base déjà migrée.
Sync Fare Prices — réaligne le prix des billets déjà migrés sur celui de l'événement source (les prix à 0,00 € ne sont jamais appliqués, pour ne pas écraser un tarif par une valeur non renseignée).
Sync Publication & Archiving — réaligne la publication et l'archivage des programmes et séances déjà migrés sur l'état de leur événement source.
Backfill Dates & Seats — complète les dates et les jauges qui seraient restées vides sur des programmes, séances ou billets déjà migrés, sans toucher aux valeurs déjà renseignées.

Chacune de ces actions vous montre exactement ce qu'elle va changer avant de vous demander de confirmer.

Contrôler avant de couper la vente côté Événement¶

C'est l'étape la plus importante : ne touchez pas encore à vos événements d'origine. Les programmes créés par la migration arrivent volontairement non publiés, pour que rien ne change côté client tant que vous n'avez pas vérifié vous-même que tout est correct.

Avant d'aller plus loin, contrôlez côté Billetterie :

Les programmes migrés existent, avec les bonnes informations (nom, description, image).
Les prix des billets correspondent à ceux pratiqués côté Événement.
Les séances sont visibles avec les bonnes dates et les bonnes jauges.
Un parcours d'achat complet fonctionne — sur le site comme au point de vente si vous y vendez également —, jusqu'à obtenir un billet valide.

Une fois ces contrôles faits et les programmes concernés publiés, vous pouvez couper la vente côté Événement.

Dépublier les événements Odoo Événement¶

La migration ne dépublie et n'archive jamais vos événements d'origine — ce choix reste le vôtre, au moment où vous êtes prêt. Utilisez le mécanisme standard d'Odoo, pas un bouton de ce wizard :

Sur la page publique de l'événement (bouton Aller au Site Web depuis sa fiche), basculez le curseur Publié / Non publié en haut de la page pour qu'il ne soit plus achetable en ligne.
Depuis la fiche de l'événement, le menu Actions ⚙️ > Archiver le retire des listes actives sans supprimer son historique.

Une fois dépublié, vérifiez qu'on ne peut plus commander depuis la page Événement, puis gardez malgré tout les modules Événement installés quelque temps : ils permettent de revenir en arrière ou de contrôler un historique de vente en cas de besoin. Ne les désinstallez qu'une fois la période de vente concernée passée sans incident.