Appearance

Savoir métier — issu des formations Buchard ​

Usage : ce fichier n'est pas chargé automatiquement en session de développement (pas de préfixe @ dans le CLAUDE.md, même statut que ui-lexicon.md). Il est destiné à enrichir les réponses de la skill d'aide utilisateur côté claude.ai, qui lit l'ensemble de .claude/docs/ via le serveur MCP.

Différence avec le reste de .claude/docs/ : les docs modules/, domain/, architecture/ décrivent comment le code marche (entités, services, invariants). Ce fichier-ci capture ce qui ne se déduit pas du code : astuces d'utilisation, explications métier détaillées, cas particuliers, « pourquoi on fait comme ça », pièges terrain remontés en formation ou par les équipes.

Ne pas y mettre : noms d'entités, chemins de fichiers, détails d'implémentation. Ça, c'est le rôle des autres docs. Ici on parle le langage de l'utilisateur (voir ui-lexicon.md pour les libellés exacts).

Comment lire ce fichier ​

  • Ce qui est vérifié (dit en formation, confirmé par une équipe) et ce qui est supposé doivent être distingués. Marquer [À CONFIRMER] tout ce qui n'est pas sûr.

1. Contexte général ​

Intégrations ​

  • Business Central (BC) — logiciel de gestion/compta. Horizon échange avec BC : clients, factures, TVA, axe d'affaires, gammes de voyages, numéro NAV, écritures et paiements.
  • Site web Buchard — alimenté par les données de voyage saisies dans Horizon.
  • Application mobile — alimentée aussi par ces mêmes données.
  • Visual Planning — outil externe de gestion de ressources (chauffeurs, hôtesses, véhicules réels), synchronisé chaque matin (voir §18).
  • Prestataires de paiement en ligne — SaferPay (et un second prestataire configuré) pour les paiements web (voir §21).

2. Navigation générale (menu) ​

Grands blocs de l'application :

  • Tableau de bord
  • Commentaires
  • Administration (dont Gestion des utilisateurs)
  • Paramètres (dont Finance)
  • Client (Gestion des clients)
  • Voyage (design des voyages : catalogue, course d'un jour, balnéaire)

3. Tableau de bord ​

Simple. Son contenu change selon le profil de l'utilisateur connecté.

4. Commentaires ​

  • Ce sont les commentaires provenant du site web.
  • Gérés par le marketing (pas par la production ni la finance).
  • Actions possibles dans l'interface : approuver, désapprouver, répondre, éditer.
  • Un compteur (petit chiffre) apparaît à l'arrivée d'un nouveau commentaire.

5. Administration > Gestion des utilisateurs ​

  • Liste des utilisateurs avec leur statut.
  • Un utilisateur avec une icône Microsoft = compte SSO.

6. Paramètres > Finance ​

La section Paramètres ne contient (pour l'instant) que la Finance. Elle regroupe des réglages qui servent surtout au calculateur de prix de la création de voyage.

6.1 Réglages (paramètres généraux) ​

  • Simple formulaire de paramètres généraux (réductions enfants, prix chauffeurs, charge de structure, etc.).
  • Ces valeurs alimentent le calcul de prix lors de la création d'un voyage.
  • Snapshot par voyage : au moment où un voyage est créé, une copie figée des paramètres est prise, pour que le voyage ne « bouge » pas si les réglages évoluent ensuite.
  • Ces paramètres changent peu (au plus ~1×/an).

6.2 Devises ​

  • Objectif prévu : convertir les prestations libellées en euros vers des francs suisses (CHF), pour obtenir un total réel en CHF et calculer marge / rentabilité.

6.3 TVA ​

  • Configuration simple de la TVA, utilisée dans les calculs.
  • La TVA saisie ici doit correspondre exactement à celle de Business Central. Horizon calcule les prix et envoie les montants à BC en utilisant ce taux ; une TVA mal réglée provoque des affichages/prix faux dans Business Central.
  • Il existe trois régimes de TVA (voir aussi §9.7 – onglet Résumé) :
    • Export : pas de TVA.
    • Suisse : TVA à 8,1 % (ou la TVA configurée dans le système).
    • Zone rose : TVA calculée non sur le prix du voyage, mais sur un forfait de 25 CHF par personne.
      • Mécanique : on sort 25 CHF/personne du prix du voyage, on applique 8,1 % dessus, on diminue le prix du voyage du montant correspondant et on ajoute une ligne dédiée en compta portant la TVA. Exemple : 4 personnes → 4 × 25 = 100 ; on retire 100 du prix voyage et on crée une ligne de 100 sur le compte TVA.

6.4 Assurances ​

  • Plusieurs types d'assurance : Voyage en car, Voyage balnéaire, etc. Course d'un jour : pas d'assurance.
  • Le tarif dépend d'une tranche de montant du voyage et d'un prix fixe par personne. Ordre de grandeur (exemples) :
    • 1 – 500 CHF → ~19 CHF/personne
    • 500 – 1000 CHF → ~37 CHF/personne
    • 1000 – 1500 CHF → ~56 CHF/personne
  • Validité par période (ex. 2024–2025) : c'est la date de départ du voyage qui fait foi. Un voyage partant en 2027 prend les assurances 2027. Conséquence : si une date passe d'une année à l'autre, le montant d'assurance peut changer (rappel du montant selon la config de l'année).
  • Export possible : bouton d'export vers Excel (choisir date de début / date de fin).
  • ⚠️ Cas particulier « enfant en chambre double » (assurance faussée) :
    • Tout est calculé par personne. Le système répartit le montant de la chambre à parts égales entre occupants (ex. chambre à 900 → 450/personne → tranche 1–500 → 19 CHF).
    • Or pour un adulte + un enfant, le prix « réel » de l'enfant est plus faible (avant, ils ventilaient : chambre 450 mais enfant compté ~150). Comme Horizon ne connaît pas le montant ventilé de l'enfant dans une chambre double, l'assurance de l'enfant ressort fausse.
    • Contournement actuel : correction manuelle (édition du PDF) côté métier.

6.5 Suppléments globaux ​

  • Fonctionnalité récente, ajoutée en mai 2025 suite à la hausse du carburant (contexte géopolitique / prix à la pompe), avec répercussion aussi sur vols et bateaux.
  • Pourquoi un module dédié plutôt qu'un simple champ : des réservations étaient déjà faites. Il fallait pouvoir refacturer le supplément sur des dossiers existants (voir logique acompte/solde ci-dessous).
  • Paramétrage : montant, date de début (pas de date de fin pour l'instant), et mode de calcul.
    • Forfait unique (par personne, indépendant du nombre de jours) — typiquement pour un vol.
    • Par jour (montant plus petit, multiplié par jour) — typiquement quand chaque étape en car génère un surcoût.
  • Mode d'application finement paramétrable : plage de dates, occurrence spécifique, ou date balnéaire spécifique ; possibilité d'inclure/exclure des dates ; état actif/inactif.
  • Se répercute automatiquement sur la facturation, le site web et l'application mobile. Un texte explicatif est affiché (courrier + site web) pour justifier la hausse auprès du client.
  • ⚠️ Piège de configuration : un supplément saisi puis activé avant d'avoir restreint ses occurrences peut se poser par erreur sur des réservations faites entre-temps (voir la méthode de diagnostic en §26).

Logique acompte / solde appliquée au supplément ​

Lors d'une réservation, le client paie soit l'acompte (35 % ou 50 % selon le type de voyage), soit la totalité. Le processus de facturation envoie l'acompte, puis facture le solde ~30 jours avant le voyage. Pour le supplément carburant :

  • Client ayant payé l'acompte → il reste à facturer le solde + le supplément.
  • Client ayant payé la totalité → il reste à facturer uniquement le supplément (d'où des factures de quelques francs qui surprenaient les clients, expliquées par courrier).

7. Client ​

7.1 Gestion des clients ​

  • Formulaire simple avec statut du client, indication actif/inactif, origine (invité ou non).
  • Synchronisation avec Business Central : unidirectionnelle (Horizon → BC).
    • Une modification enregistrée dans Horizon déclenche un appel à l'API BC → mise à jour dans BC.
    • Une modification faite dans BC ne redescend pas dans Horizon (normalement le métier ne modifie pas côté BC).
  • ⚠️ Conséquence de perf : Horizon ne stocke pas toutes les infos ; une partie des données vit dans BC. Sur les listes (ex. facturation), Horizon va rechercher les données dans BC pour chaque client → ralentissements notables.

7.2 Fiche client — contenu ​

  • Passagers ayant voyagé avec cette personne.
  • Voyages réservés.
  • Factures : c'est un snapshot de Business Central, ré-affiché dans une interface lisible (identifiant voyage, n° de résa, document…), car BC est peu lisible en direct.
  • Bons cadeaux achetés et bons cadeaux utilisés.
  • Points de fidélité : historique complet (achat de voyage, téléchargement de l'app ≈ 250 points, adhésion au club, utilisations…). Chaque achat/utilisation/modification de réservation impacte le solde. (Volet piloté par Loïc.)

8. Voyages — concepts communs ​

8.1 Types de voyage ​

  • Voyage catalogue
  • Course d'un jour
  • Voyage balnéaire
  • Hors catalogue — quasi non utilisé (parfois pour un voyage spécifique / privatisé, non affiché sur le site).
  • Voyage en groupe — non utilisé.

8.2 Structure de base ​

Règle fondamentale à retenir :

  • Un voyage catalogue / course d'un jour = 1 voyage + des dates.
  • Un voyage balnéaire = 1 voyage + 1 date + une couche « destination » au-dessus (voir §11).

8.3 Statuts d'un voyage ​

  • Brouillon — non réservable.
  • Brouillon mais réservable en interne — non publié sur le site/app, mais réservable directement dans Horizon (pré-réservations, dossiers internes, voyages non publics).
  • Publié — visible sur le site web et l'application.

8.4 Duplication & cycle de vie des dates ​

  • Pour la saison suivante, on duplique le voyage puis on met les nouvelles dates (l'onglet Général contient des infos qui changent d'une année à l'autre → on ne réutilise pas tel quel).
  • Le voyage dupliqué garde un lien vers le voyage principal (chaînage, retrouvable au besoin).
  • Tant qu'un voyage a des dates actives, on peut ajouter de nouvelles dates (ex. 2ᵉ catalogue dans l'année, ajout de dates en janvier).
  • Quand le voyage est terminé (plus de dates en cours), il faut le dupliquer pour repartir — sinon on accumule un nombre ingérable de dates et l'historique/description ne correspond plus.
  • Archivage automatique : dès qu'un voyage n'a plus de dates en cours, il apparaît dans les archivés.

8.5 Lignes de chargement — Lignes › Trajets › Lieux ​

Structure hiérarchique utilisée pour organiser la prise en charge des voyageurs :

  • Ligne (ex. Ligne A).
  • Trajets rattachés à une ligne (ex. Genève, Fribourg, La Chaux-de-Fonds…).
  • Lieux : les points précis où l'on vient chercher les gens.
  • Des horaires sont rattachés aux lieux selon le voyage : les horaires affichés sont théoriques ; lors de la planification du bus, on met le vrai horaire.

Lignes de chargement (aller) vs lignes de déchargement (retour) :

  • Le retour peut emprunter une ligne différente de l'aller (ex. départ Corse par Gênes, retour plein → retour par Marseille).
  • Pour le client, ça ne change rien tant que le lieu reste le même : un même lieu peut appartenir à plusieurs lignes/trajets.
  • S'il n'y a pas de ligne de déchargement, le retour est identique à l'aller.

🛠️ Refactor des lieux (fait ~1 mois avant la formation) : auparavant, un même lieu physique existait en plusieurs exemplaires en base (même libellé affiché, enregistrements distincts). Au changement de ligne, un rapprochement (matching, type distance de Levenshtein) était utilisé et le lieu pouvait être « perdu ». Désormais : un seul lieu, des garde-fous partout. Si un lieu ne fait pas partie de la ligne choisie, l'interface affiche un avertissement (« la personne est dans un lieu qui n'existe pas »).

9. Voyage catalogue — les onglets ​

L'interface de création est dense. Ordre des onglets : 1 Général · 2 Photos · 3 Calendrier · 4 Dates · 5 Journées · 6 Hébergement · 7 Résumé. Beaucoup d'informations servent d'abord à alimenter le site web et l'app.

9.1 Onglet Général ​

  • Nom, sous-titres → site web.
  • Assurances sélectionnables pour ce voyage.
  • Acompte (ex. 35 %).
  • Axe d'affaires → Business Central.
  • Gammes de voyages → Business Central.
  • Voyage Globe : ancien champ lié à une importation, plus utilisé.
  • Documents ajoutables → apparaissent sur la facture.
  • Coups de cœur → site web.
  • Lignes de chargement (voir §8.5) : élément important de cet onglet.

9.2 Onglet Photos ​

  • Pour le site web et l'application mobile. Gérées par le métier.

9.3 Onglet Calendrier ​

  • Choix des dates. Une date en rouge = annulée.
  • Cliquer sur une date l'enregistre ; la durée (nombre de jours) se règle et détermine la date de fin.

9.4 Onglet Dates (particularités par date) ​

Permet de surcharger certaines données pour une date précise :

  • Véhicule : ajout de véhicules (44 places, 48 places…). Si un véhicule est associé, le client voit le plan et peut choisir sa place à la réservation.
  • Contingent : si pas de plan de véhicule, on définit une capacité totale (contingent). Atteint = complet.
  • Lignes personnalisées : par date, on peut définir aller Ligne A / retour Ligne B, ou l'inverse à la date suivante → liberté totale par date.

Note « places / plan de véhicule » : on met d'abord une catégorie de bus (ex. 44 places, dont il existe ~10 exemplaires) ; le vrai bus qui part est déterminé plus tard par la planification dans Visual Planning. L'affectation des personnes sur les sièges se fait au moment de la réservation.

9.5 Onglet Journées ​

  • Sert au site web : trajets par journée, descriptions jour par jour (« jour 1 on va là, jour 2 on fait ça… »), carte.
  • Ce n'est pas que décoratif : les trajets saisis permettent de calculer les kilomètres et donc d'alimenter la proposition de prix.
  • Hébergement défini ici : on peut en ajouter plusieurs, avec un principal.
    • Cas d'un hôtel intermédiaire (long trajet Espagne/Portugal : nuit d'étape à l'aller, éventuellement un hôtel différent au retour).
    • ⚠️ Bien cocher « principal » : les hôtels non principaux (intermédiaires) n'apparaissent pas de la même façon.
  • Excursions facultatives sélectionnables → s'ajoutent à la réservation (ex. balade à cheval, tour en moto…).

9.6 Onglet Hébergement ​

  • Reprend l'hôtel choisi et définit les contingents de chambre (ex. single : 5, double : 19).
  • Prix des chambres : prévus pour alimenter le calcul, mais pas utilisés actuellement — le métier saisit le prix final manuellement (voir §9.7). Le contingent, lui, est bien saisi et utilisé.
  • Stop sales : bloque la vente d'une chambre même si le contingent n'est pas atteint.
  • Comportement quand le contingent est atteint :
    • En interne : réservation encore possible (affichage type alerte), car le métier peut appeler l'hôtel et augmenter le contingent après coup.
    • En stop sales : rouge, réellement bloqué, réservation impossible.
    • Sur le site web : contingent atteint ou stop sales → bloqué (le métier garde une marge de manœuvre en interne).
  • Les contingents varient par date (jamais forcément le même d'une date à l'autre).
  • Repères de couleur des chambres/contingents à la réservation : voir §14.8.

9.7 Onglet Résumé (calcul de prix) ​

  • Système de calcul complet mais NON utilisé aujourd'hui. Il agrège : jours de voyage, distances/kilomètres, coût du trajet, coût RH, coût de structure, autres frais, coût d'achat, hébergement, excursions…
  • Numéro NAV = identifiant Business Central à saisir ; il fait la liaison voyage ↔ facture.
  • Global ID : lié à l'ancienne importation.
  • Cours EUR/CHF : réutilisable si le voyage est calculé en euros.
  • Autres infos configurables : présence d'un avion / d'un bateau, nombre de minutes de travail/jour, tour-opérateur et prix TO, forfait hôtel/chauffeur, etc.
  • Seul paramètre réellement utilisé aujourd'hui dans cet onglet : la TVA (régime export / Suisse / zone rose — voir §6.3).
  • Tableau de projection : selon le nombre de personnes, prix par personne estimé (ex. 28 pers → ~600 ; 36 pers → ~530). Objectif métier : ne plus vendre à perte (historiquement, certaines lignes partaient par habitude avec trop peu de passagers).
  • Prix proposé vs prix choisi :
    • Le prix proposé est calculé (aujourd'hui faux car les infos amont ne sont pas remplies).
    • Le prix proposé est un prix par chambre (chambre complète) ; le métier le surcharge avec le prix choisi = prix définitif mis en vente, par date et par type de chambre.
    • Affichage site web : « chambre double, par personne » → division par 2 d'une chambre double.

10. Course d'un jour ​

Plus simple qu'un catalogue.

  • Général : mêmes infos de base.
  • Photos.
  • Trajets : au lieu d'une ligne de chargement, on met des trajets spécifiques à ce voyage d'un jour. On peut réutiliser un trajet existant (ex. trajet d'une ligne) ou créer un trajet custom (interface de saisie de trajets : lieux existants + horaires spécifiques).
  • Calendrier : dates.
  • Particularités par date : plan de car → capacité totale par véhicule ; sinon contingent. Les lignes sont débloquées selon les dates (ex. le 5 → trajet 1 ; le 7 novembre → ligne 3 avec 44 ; parfois deux trajets) → contingents/capacités par ligne et par trajet ; c'est ce qui bloque la réservation.
  • Excursions facultatives.
  • Résumé : pas de tableau par hébergement (il n'y en a pas). On saisit :
    • Prix voyage, prix junior, prix enfant,
    • Prix aller simple / retour simple (ex. prendre le bus pour aller à Europa Park mais rentrer autrement).

Tranches d'âge (course d'un jour) : définies en dur dans le système. À l'inverse, pour l'hébergement (catalogue/balnéaire), les tranches d'âge sont configurables par hôtel (chaque hôtel a ses propres bornes junior/enfant), donc pas en dur.

Exemple Europa Park : ils ne partent pas toujours des mêmes arrêts. Chaque date débloque les lignes/trajets voulus, avec un contingent par ligne. Pour les courses d'un jour, les places dans le bus ne sont assignées que plus tard (voir §17), lors de la préparation ~30 jours avant.

11. Voyage balnéaire ​

Trois destinations : Majorque, Costa Brava, IGEA.

11.1 La couche supplémentaire : Destination › Date › Hôtel ​

  • Là où un catalogue = voyage + dates, un balnéaire ajoute une destination au-dessus.
  • Le voyage EST l'hôtel : pour une même destination et une même date, il existe un « voyage » par hôtel.
  • Les voyageurs d'une même date/destination sont dans le même avion (ou bus) mais répartis dans des hôtels différents.

11.2 Création d'un voyage balnéaire ​

  • Type de voyage = Balnéaire → choix de la catégorie/destination (Costa Brava, IGEA, Majorque) → choix de l'hébergement (hôtel).
  • Saisie hôtel : catégorie, description (« petit hôtel familial »…), et infos habituelles.
  • Photos, Transport (détail des trajets aéroport, calcul), Excursions facultatives : comme ailleurs.

11.3 Départs (calendrier) ​

  • Beaucoup de départs (souvent tous les jeudis/vendredis) → générateur de dates : date de début, date de fin, nombre de nuits (7, 14…) → génère automatiquement le tableau des dates.
  • Ajout manuel d'une date possible (ex. client qui veut rester du 10 sept. au 1er oct.) : on ajoute la date et un prix custom. Ça ne pose pas de problème car il y a des contingents séparés pour la date de départ et pour la date de retour.

11.4 Contingents & capacités (balnéaire) ​

  • Chambres : en général pas de contingent par chambre (mis à 99 / illimité), sauf blocage de réserve.
  • Transport : contingent, comme pour les courses d'un jour.
  • ⚠️ La capacité est partagée par destination + date, pas par hôtel.
    • Ex. capacité 110 = capacité de l'avion pour Majorque ; fixe.
    • Pour une date donnée, on peut avoir 3 personnes à l'hôtel Gaïa et 10 dans un autre : c'est l'occupation cumulée de la destination qui compte.
  • Couche de gestion au-dessus (« Balnéaire › ajouter/modifier ») : on définit par destination + date de départ / retour un contingent (ex. Majorque, 78 pour le 8 octobre au retour ; départ/retour distingués), avec ou sans plan de car.
    • Sans plan de car → capacité type 110 personnes.
    • Avec plan de car → le car choisi détermine le nombre de places disponibles.
  • Surcharge manuelle possible: (Vols secs par ex: client qui ne prend que le vol, se débrouille pour l'hôtel) : peu prioritaires. Sur la capacité globale, un surcontingent (ex. ~10 personnes) leur est réservé/limité, sur-définissable par voyage/hôtel.

11.5 Hébergement & prix (balnéaire) ​

  • Prix par occupation de chambre : ex. 2 adultes ; 2 adultes + 1 enfant ; etc. Certaines combinaisons n'existent pas (pas de prix) → non proposées.
  • Configuration au niveau de l'hôtel (on ne change pas souvent les hôtels) :
    • Types de chambres (double, double à usage individuel, cabines…), avec libellé personnalisé possible (« chambre ultra confort »…) mais type sous-jacent conservé (reste une double).
    • Options de chambre (vue mer, vue piscine, jacuzzi…) : ne changent pas le type mais ajoutent un supplément de prix.
  • Prix par date : les prix se saisissent pour toutes les dates (souvent identiques → astuces de copie, voir §12).

11.6 Résumé (balnéaire) ​

  • Comme la course d'un jour : on saisit un prix de vente du « voyage » qui s'ajoute au prix de la chambre.
  • État actuel : le prix de la chambre inclut « tout compris » (saisi globalement). Cible : ne mettre ici que le prix d'hébergement, et laisser Horizon calculer la marge et le prix de vente qui s'ajoute automatiquement au prix de chambre.
  • Raison de l'affichage par personne sur le site : faire comprendre au client que le prix comprend l'hôtel, le transport, etc. (héritage historique des habitudes de saisie).

11.7 Occupation / listes de départ ​

  • Dans les dates, l'écran occupation des véhicules calcule le taux de remplissage par destination + date (ex. 51 %, 108/110…), tous hôtels confondus (un hôtel donné peut n'avoir que 3 personnes, mais l'occupation affichée est celle de la destination).
  • C'est cette même mécanique qui sert ensuite à établir les listes de départ.

12. Astuces d'interface (à conserver) ​

  • Coller un prix sur toute une colonne (grille des prix hébergement/balnéaire) : copier le prix depuis Excel → coller dans la première cellule → il se propage vers le bas.
  • Recopier vers le bas : saisir un prix, cliquer pour le copier dans la cellule en dessous (utile quand les prix sont souvent identiques ; des indicateurs apparaissent au survol).
  • Duplication de voyage pour la saison/le catalogue suivant, plutôt que d'empiler des dates sur un voyage terminé (conserve un lien vers le voyage principal).
  • Réservation interne au-delà du contingent : possible côté métier (appel hôtel + augmentation du contingent) ; à distinguer du stop sales qui bloque réellement.
  • Pré-sélection de chambre à la réservation (single/double) pour aller plus vite (§14.3).
  • Changer de véhicule ré-attribue les voyageurs aux mêmes numéros de sièges (§17).
  • Réservation à 2 personnes : placer la 1ʳᵉ place automatiquement la 2ᵉ (§17).
  • Lien public de la liste des chambres à envoyer à l'hôtel, toujours à jour (§19).
  • Diagnostiquer une anomalie en refaisant la même réservation (§26).

13. Facturation & paiements — règle importante ​

Recréation de facture et rattachement des paiements :

  • Toute modification qui change le montant d'une facture (passager en plus, changement de chambre, etc.) provoque l'annulation de la facture et la création d'une nouvelle.
  • Un paiement déjà effectué sur l'ancienne facture est délettré puis relettré sur la nouvelle. Désormais, à chaque changement, le rattachement se fait correctement.
  • (Historiquement, ce rattachement était fait à la main.)

14. Réservation — le parcours complet ​

Le bouton Réserver n'apparaît que si le voyage est dans un statut réservable. Le parcours est identique pour les trois types de voyage ; seules quelques étapes changent (sélection de siège, cabine…).

14.1 Vue liste des dates ​

  • Affiche l'image du catalogue (PDF), les dates de début/fin, la durée, et un aperçu de l'occupation véhicule et hébergement.
  • Un petit œil ouvre l'occupation détaillée du véhicule ; l'occupation hébergement montre les chambres (ex. single 5/7).

14.2 Étape passagers ​

  • Voyageur principal = le client ; ses infos sont pré-remplies.
  • Code de réservation : champ libre pour un code externe (réf. de vol, de ferry…) ; il suit la réservation et remonte dans certaines listes.
  • Sens : aller-retour, aller simple ou retour simple (utile pour les balnéaires, pour les vols secs — un client prend le véhicule à l'aller mais rentre autrement).
  • Possibilité d'ajouter des codes avions (animaux, problème de mobilités, etc.).

14.3 Étape chambre ​

  • Pré-sélection pour gagner du temps : pour 1–2 personnes, une single ou une double est pré-sélectionnée (l'immense majorité des résas sont des singles/doubles).
  • Le prix s'affiche dès qu'une chambre est choisie et que les passagers sont assignés dans celle-ci (le prix vient de la chambre).
  • Un même voyage peut proposer plusieurs hôtels (utile quand un hôtel est complet).
  • Le type de chambre et les tranches d'âge viennent de la configuration de l'hôtel.
  • La date de naissance détermine la catégorie du voyageur :
    • Bébé : uniquement pour les vols.
    • Enfant / Junior / Adulte : pour les courses d'un jour, les âges sont fixés par Buchard (en dur) ; pour l'hébergement, ils sont définis par l'hôtel (parfois pas de junior, seulement enfant/adulte).
  • Option Twin : chambre double « twin » (lits séparés), cochée à la main ; crée un groupe spécifique dans la liste des chambres. Pas liée à une config d'hôtel.

14.4 Étape assurance ​

  • Choix sans / avec assurance ; l'assurance impacte le montant.
  • Calcul par personne : Horizon prend le prix total de la chambre divisé par le nombre d'occupants, puis applique la tranche de la table (paramètres Finance, §6.4).
  • ⚠️ Cas enfant : Horizon ne connaît pas de prix enfant ventilé → l'assurance d'un enfant en chambre partagée ressort fausse (§6.4). Le métier gère via un rabais enfant / junior saisi dans la réservation; une surcharge automatique n'est pas encore implémentée mais la demande remonte souvent.

14.5 Étape facture ​

  • Bulletin de versement : répartissable entre passagers (par défaut à parts égales ; modifiable). Utile quand deux amis partent ensemble.
  • Paiement direct possible (client au guichet) : on enregistre l'acompte (ex. 912,90) payé en cash, carte, Twint ou chèque.
  • Rabais / suppléments manuels :
    • Rabais (ex. bons Croisitour, traités comme un rabais : description + montant).
    • Supplément manuel (péage, billet 1ʳᵉ classe, etc.) — distinct du supplément global (§6.5), qui est automatique.
    • ⚠️ Un rabais posé sur la réservation ne touche l'acompte que si on coche « comptabiliser sur la confirmation ».
  • On peut aussi saisir le numéro d'un bon cadeau ici.
  • À l'enregistrement, la réservation est créée sur le compte ; on peut ensuite voir la facture (PDF).

14.6 Modifier une réservation ​

  • Tout est modifiable après coup (ajouter un passager, changer une chambre…).
  • Changement de nom / date de naissance (sans impact sur le montant) : la facture ne bouge pas, pas d'appel à Business Central.
  • Changement de montant : Horizon annule la facture précédente (note de crédit) et en crée une nouvelle. Les paiements sont conservés et transférés vers la nouvelle facture par le lettrage/délettrage ; le solde reste juste (voir §13).
  • On ne peut pas ré-enregistrer un paiement dans la réservation si un paiement y a déjà été ajouté → passer par le menu Paiement (§23).

14.7 Réserver un voyage complet ou déjà facturé ​

  • Un voyage complet reste réservable en interne (ça ne bloque pas), pour les pré-réservations : on met en provisoire, on appelle l'hôtel, on ajuste le contingent.
  • Sur le site web, complet ou stop sales = bloqué (message « indisponible »).
  • Si le voyage est déjà facturé : la réservation reste possible mais il faut envoyer la facture complète — soit passer la résa directement en facturé (facture finale générée), soit repasser par l'écran de facturation.
  • Lieux de chargement proposés : une fois le tableau de chargement fait et le voyage facturé, seuls les lieux ayant un horaire sont proposés. Une case « afficher les lieux indisponibles » permet d'en choisir un autre — en accord avec la planif. Toute nouvelle résa sur un voyage déjà planifié déclenche une notification à la planif (pour adapter le tableau de chargement).

14.8 Couleurs de contingent & prix à zéro (à checker) ​

Repères visuels sur les chambres/contingents :

  • Jaune : contingent atteint mais gérable en interne.
  • Rouge : aucun contingent configuré pour cette chambre → il y a de grandes chances qu'il n'y ait pas non plus de prix.
  • Prix à zéro — premiers réflexes : soit des options ont été sélectionnées, soit l'hôtel a une configuration en double (deux variantes identiques, le prix n'étant saisi que sur l'une). Il faut remplir les occupants pour que le prix se calcule.

14.9 Croisière : sélection de cabine ​

  • Pour les croisières, un bouton « cabine » ouvre un plan (comme le plan du bus) pour choisir la cabine.

15. Facturation (le jour de facturer) ​

  • Accès : Dates > en cours > Action > Facturé. L'écran liste les réservations (annulées, confirmées, liste d'attente).
  • On voit l'acompte, le solde restant et le total, calculés à partir des données Business Central.
  • Options de facturation : télécharger les factures après enregistrement ; inclure ou non les réservations internet (case dédiée). L'enregistrement fait passer les résas en facturé.
  • Lenteur normale : l'écran ne peut pas être accéléré — il faut écrire les factures dans Business Central, dont l'API n'est pas très rapide. Non bloquant (facturation par lots).
  • Le fichier des factures est téléchargé pour impression.

16. Tableau de chargement & plan de déroulement ​

  • Non automatisé (par choix) : les équipes le font manuellement pour garder le contrôle. Elles font d'abord le tableau de chargement (pour que l'heure apparaisse sur la facture), puis facturent.
  • Réalisé ~30 jours avant le départ (pas à la réservation) : les résas rentrent en continu et changent tout ; c'est un objet « vivant ».
  • Aller et retour distincts : le retour n'emprunte pas forcément la même ligne (§8.5).
  • Chauffeurs de chargement : un par trajet. Ils vont chercher des séries de voyageurs aux lieux de prise en charge et les amènent au véhicule principal. Le premier chauffeur de chargement est souvent le chauffeur du voyage.
  • Les noms des chauffeurs et hôtesses viennent directement de Visual Planning (API appelée en direct — voir §18).
  • Horaires : édités à la main dans le tableau (10h, 10h10, 10h20…) ; l'heure définitive remonte ensuite sur la facture / le PDF de la réservation.
  • Export « vintage » : le design du tableau reprend les données du formulaire de saisie du tableau de chargement.

17. Assignation des places & plan des passagers ​

  • Écran distinct des tableaux de chargement.
  • Réassignation : si un client a choisi un siège, on peut le déplacer manuellement.
  • Changer de véhicule (ex. passer d'un 44 places à un 50 places parce qu'il reste des chambres) : supprimer le véhicule (désassigne les gens, l'historique est conservé) puis ajouter le nouveau → les gens sont réattribués aux mêmes numéros de sièges. Les places particulières (ex. situation de handicap) sont préservées.
  • Bloquer un siège : clic sur le siège (même occupé) → « siège bloqué ». Il n'est plus réservable ni déplaçable, y compris sur le site web et l'app mobile.
  • Propagation immédiate : tout changement de véhicule ou de contingent est répercuté en direct sur les réservations en ligne, l'app mobile et l'interne.
  • Balnéaire : on assigne par destination aller / retour. Astuce : sur une résa de 2 personnes, placer la 1ʳᵉ place automatiquement la 2ᵉ. Plusieurs filtres / tris (par lieu de réservation…) selon les habitudes des équipes.

18. Ressources & Visual Planning ​

Les ressources s'assignent par date/voyage.

  • Hôtesses et chauffeurs : proviennent de Visual Planning, via une synchro chaque matin. Deux ou trois catégories sont synchronisées automatiquement ; une nouvelle catégorie côté Visual Planning doit parfois être ajoutée manuellement.
  • Musiciens : ajoutés manuellement.
  • Véhicules : le vrai véhicule vient de Visual Planning (avec son identifiant réel) ; à distinguer de la catégorie de véhicule configurée dans Horizon (§25.2).
  • Accompagnateurs : gérés ici, hors contingent client (les compter dans le contingent n'aurait pas de sens). On peut leur assigner une chambre et un siège. En général ≤ 4 personnes ; souvent les équipes se contentent de bloquer des sièges pour eux. L'important est que l'info « accompagnateur » remonte dans les listes.

Visual Planning est un outil externe de gestion/assignation de ressources, utilisé par la logistique pour planifier véhicules + chauffeurs. Auparavant (ancien outil « Globe »), on créait de fausses réservations pour les chauffeurs, ce qui n'avait pas de sens ; c'est désormais une vraie assignation de ressources.

19. Listes & documents de départ ​

Par date, plusieurs listes exportables (PDF) :

  • Liste des passagers, plan de déroulement (aller), plan de déroulement retour, plan des véhicules, liste des chambres, liste des excursions facultatives.
  • Plan de déroulement : tous les trajets avec leurs horaires (et la date de retour si différente en balnéaire). Ordonné par heure (10h, 10h10…), et non par l'ordre de base de la liste.
  • Liste des chambres : les chambres Twin forment un groupe spécifique ; on y voit les accompagnateurs et, en balnéaire, des dates de check-in / check-out (séjours de 1, 2 ou 3 semaines).
    • Un lien public (sans menu, accessible sans connexion) permet d'envoyer la liste à l'hôtel, toujours à jour — évite de renvoyer un PDF à chaque changement.
    • Option « groupé par véhicule ».
  • Balnéaire : comme chaque voyage est un hôtel, sortir les listes sous un voyage les donne par hôtel ; les sortir sous Balnéaires (par destination) les donne pour tous les hôtels d'une même date.
  • Course d'un jour : seulement plan de chargement / plan de déroulement.
  • Cas particuliers : une liste liée aux vols apparaît partout même sans vol ; une liste Europa Park existe ; d'autres documents (attestation d'excursion, offre de course…).

20. Bons cadeaux ​

  • Achat / offre : le plus souvent, une personne achète un bon et l'offre à une autre. Payé = utilisable, y compris partiellement (un montant restant subsiste après usage, réutilisable sur une prochaine résa).
  • Annulation d'une réservation payée avec un bon → le montant revient sur le bon.
  • Actions marketing (case à cocher) — détermine la ventilation en compta :
    • Promo Buchard : tout payé par Buchard.
    • Concours / partenariat (ex. une radio) : une partie payée par le partenaire, une partie par Buchard.
    • Dédommagement : compensation client (problème sur un voyage), tout payé par Buchard.
    • Un bon partiellement marketing (ex. 100 dont 50 marketing) génère deux écritures/factures en compta (une Buchard, une client).
  • Options : envoi par enveloppe, afficher les remarques, valeur, afficher le nom du client / du bénéficiaire, enregistrer un paiement directement.
  • Restaurer ou marquer comme utilisé (deux options). Effacer un bon (s'il n'est pas utilisé) supprime les écritures comptables liées ; si le compte a un solde, le remboursement client se fait à la main (écriture comptable séparée).
  • Les bons cadeaux sont achetables en ligne (voir §21 pour les paniers abandonnés).

21. Paiement en ligne : panier abandonné & worker ​

21.1 Panier abandonné ​

Concerne trois cas : bons cadeaux, réservations, adhésion au club.

  • Quand quelqu'un commence un achat en ligne sans aller au bout du paiement, l'entrée apparaît en panier abandonné (statut « aucune validation »). Les équipes peuvent relancer (rappel du client) — pratique standard de récupération de panier.
  • Adhésion au club abandonnée : statut similaire, mais seulement « annuler » (pas de « relancer »). Annuler supprime le type d'adhésion, le code et la date. (Évite les cas où un client recevait la facture d'adhésion + le renouvellement.)

21.2 Worker de paiement ​

Quand un client paie en ligne, le paiement passe en « en attente », et un worker tourne chaque minute pour traiter les paiements en attente. Pour chaque paiement, le worker :

  1. envoie au prestataire de paiement (SaferPay, ou Cembra) l'ID de transaction + le montant à débiter, et valide le paiement ;
  2. crée la facture dans Horizon ;
  3. enregistre un paiement dans Horizon (pour signaler à la compta que l'argent va arriver) ;
  4. passe le statut à « confirmé » ou « facturé » selon si il décide de payer la totalité ou l'acompte pour les réservations ou simplement à « payé » pour les bons et l'adhésion au club puis envoie un mail de confirmation au client.
  • Pourquoi un worker : le process est lourd et dépend de BC et de la plateforme de paiement ; il réessaie (5 fois). En cas d'échec persistant, le statut passe à « erreur » et les équipes reçoivent un mail.
  • Bouton « relancer » : repasse le statut en « en attente » → le worker réessaie (ça passe souvent plus tard, ex. SaferPay bloquant temporairement pour vérifications).
  • Idempotence : le worker marque « paiement fait / mail envoyé » pour ne pas re-débiter ce qui l'a déjà été et reprendre seulement l'étape qui a échoué.

21.3 Auto-nettoyage des doublons ​

  • Un client qui fait plusieurs allers-retours peut créer plusieurs réservations « aucune validation » (et, en invité, plusieurs comptes clients).
  • Quand il finalise, le worker repère les tentatives (même client, même voyage) et les efface automatiquement ; un compte invité sans réservation rattachée est supprimé dans Horizon et dans Business Central. Le système s'auto-nettoie — les doublons ne sont donc pas un problème (une résa non finalisée peut aussi être effacée à n'importe quel moment par un utilisateur, ses comptes clients rattachés partant avec).

21.4 Anti-surbooking ​

  • Une réservation dont le paiement est « en attente » ou « erreur » est considérée comme pending et bloque la place.
  • Couche supplémentaire : s'il ne reste qu'une place, quand un client est sur l'interface de paiement (statut « aucune validation », < 30 min), un autre client qui tente derrière reçoit « quelqu'un a réservé, réessayez ». Un client reste aveugle à sa propre réservation (ses allers-retours ne se bloquent pas eux-mêmes).
  • Cas résiduel : deux clics exactement simultanés peuvent encore surbooker (rare) — les équipes contrôlent de toute façon.

21.5 Reprise par les équipes ​

  • Une réservation en attente peut être reprise par une équipe à la place du client : éditer → passer en confirmé → finaliser → envoyer la facture. Toutes les infos sont déjà là, il suffit de compléter.

22. Notes ​

  • Bouton « notes », transversal : des notes peuvent être posées à plusieurs endroits (voyage, réservation, facture…) et remontent ensuite dans les listes et tables. Un tag indique l'origine (ex. une note voyage).
  • Notes de voyage : infos pratiques que la réservation peut transmettre au client (ex. « Séjour 2026 », « contingent, hôtesse incluse »).
  • Demandes particulières en réservation : « pas près des toilettes », « à côté de ma femme », « loin de… » — utile notamment pour les courses d'un jour où le client ne choisit pas sa place.
  • Modèles de notes : notes pré-rédigées réutilisables (ex. « étage supérieur, si possible avec une table », « personne à mobilité réduite »). On peut aussi ajouter une note manuelle, pour la réservation ou pour la facture.

23. Recherche factures & interface paiement (Client) ​

  • Factures : moteur de recherche des factures (dès qu'une résa est facturée). On voit le montant restant, qui a fait quoi ; on peut sortir le PDF, voir/ajouter des notes, et exporter le résultat en PDF.
  • Paiement : ajouter un paiement → choisir le client, puis ce qu'on paie (solde d'une résa, bon cadeau, facture du club). Valider la date, la source (ventilation compta) et le montant.
    • Message « dépasse le solde restant à payer » si le montant est trop élevé, et indication claire si c'est déjà payé (solde à zéro) — ajouté pour éviter les erreurs.

24. Autres modules ​

  • Offres spéciales : rabais ciblés pour des voyages (promo Noël, promo membres du club, relance d'un voyage qui se vend mal…). On choisit un voyage ou une date, un nom, une valeur ; possibilité de calculer la valeur par personne (ex. 10 CHF × 2 personnes). S'applique automatiquement dans le process de réservation.
  • Gammes de voyage : catégories de voyage, liées à un slug, servant à filtrer les voyages affichés sur le site (URL propre par gamme).
  • Destinations : les trois destinations balnéaires (§11), utilisées pour l'affichage des blocs sur le site. Rarement touchées ; l'ajout d'une destination est possible mais non prévu.
  • Rooming balnéaire : interface de suivi quotidien des réservations du jour (contrôle de ce qui a été réservé) — très utilisée.
  • Rapports : différents formulaires de recherche pour afficher des statistiques selon les besoins (Vente, direction, logistique).

25. Configuration : lignes, lieux, véhicules, hébergement ​

25.1 Lignes, trajets, lieux ​

  • Lignes : créer une ligne (nom), composer les trajets, puis les lieux dans chaque trajet (§8.5).
  • Horaires : posés sur le trajet, dans un onglet séparé. Un même trajet peut avoir plusieurs horaires (donc potentiellement deux horaires affichés sur le site).
  • Lieux : base nettoyée (chaque lieu montre à quel trajet il est rattaché — voir le refactor en §8.5).

25.2 Transport (catégories de véhicule) ​

  • Ici, catégorie de véhicule (ex. « 44 places ») — pas le véhicule réel de Visual Planning. On configure les étages, le nombre de véhicules et une capacité définie (c'est elle qui bloque les résas quand un voyage n'a ni plan de car ni contingent propre).
  • Finances du véhicule : coût au kilomètre, charges d'amortissement — utilisés dans le calcul de prix du voyage.
  • Configurateur de plan de véhicule : après création, on « dessine » le plan (image de fond, nombre de colonnes/rangées, déplacement des zones avec les champs du formulaire, taille des sièges, image de siège). Fait une fois puis rarement retouché. Même principe que le plan de cabine pour les croisières (image + reconstruction du plan par-dessus).

25.3 Hébergement (hôtels) ​

  • Configuration de l'hôtel : âges de l'hôtel (tranches junior/enfant/adulte propres à l'hôtel), photos (site web), et chambres via un configurateur (occupation min/max, minimum un adulte → génère le type de chambre ; âges personnalisés). La capacité liste ensuite toutes les variantes de chambres, utilisées pour les prix dans le voyage et pour le choix de chambre en réservation.
  • Pensions (surtout balnéaires) : activables ; on choisit demi-pension ou pension complète, avec des montants adulte / enfant. Selon le défaut, choisir moins applique un rabais, choisir plus un supplément.
    • ⚠️ Saisie pour 7 jours et 14 jours : le système calcule automatiquement selon la durée (il divise par 7 et multiplie par le nombre de jours). Valable pour les balnéaires, qui partent en semaines pleines (7, 14, 21 jours) ; des séjours < 7 jours casseraient le calcul, mais ce cas ne se présente pas.
  • Contingent & prix : au niveau hôtel, pas utilisés — saisis directement dans le voyage (ils changent à chaque voyage/date).
  • Excursions facultatives : gérables de façon centralisée ici, mais en pratique saisies directement dans le voyage.

26. Journal d'activité & historique ​

  • Journal d'activité : trace tout ce qui se passe dans l'application (qui a fait/modifié quoi, et quand). Recherche par ID (réservation, facture…). L'action « voir » montre les données brutes postées.
  • Historique par élément (client, réservation…) : voir qui a modifié quoi directement depuis la fiche.
  • Méthode de diagnostic (astuce terrain) : face à une situation étrange sur une réservation, refaire la même réservation. Si le problème ne se reproduit pas, c'est très probablement une erreur de manipulation / de timing de configuration, pas un bug — auquel cas créer un ticket.
    • Exemple typique : un supplément global apparu par erreur sur une résa parce que la réservation a été faite pendant la configuration du supplément (occurrences pas encore restreintes), puis la config a été corrigée sans retirer le supplément déjà posé (§6.5).

Repère d'environnement : une barre de couleur indique l'environnement — jaune sur staging, normale en production — pour éviter de manipuler la mauvaise base.

Contributors

No contributors

Changelog

No recent changes