Workflows métier principaux

Parcours utilisateur de bout en bout. À mettre à jour quand un parcours change ou qu'un nouveau workflow apparaît.

1. Création d'un voyage catalogue

1. Commercial crée un Travel en statut Draft via Pages/Travels/Create (SPA Vue travel-design).
2. Saisie des données : description, journées (TravelDay), accommodations principales et secondaires, activités, lignes de chargement/dépose, prix indicatifs, pictures, etc.
3. StageProgress permet de jalonner la création (workflow interne — utilisation à confirmer côté équipe).
4. Génération des Occurrence (instances datées) avec leurs prix par tier (SellingPrice/Junior/Child + variantes OneWay), capacités, RoomTypeQuota négociés avec hôtels.
5. Travel passe en Status = Published → visible côté API web/mobile.

2. Création d'une rotation balnéaire (Seaside)

1. Travel de type Seaside créé avec Accommodation principale et TravelCategory (= la destination, ex: Costa Brava).
2. Création des SeasideDate aller (IsReturn = false) et retour (IsReturn = true) dans Pages/SeasideDates/.
3. Plusieurs Occurrence partageant la même TravelCategoryId + Date se regroupent automatiquement sur la même rotation (= même car).
4. Affectation des véhicules par SeasideDate.

3. Réservation back-office

1. Commercial ouvre /Bookings/CreateUpdate (SPA Vue booking).
2. Étape Général : sélection client (ou création), occurrence, nombre de passagers (déclenche discount auto pour 8+ pax sauf OneDay).
3. Étape Passagers : nom/prénom/civilité/date-naissance/téléphone par passager. Si client inclus, le 1er passager est pré-rempli (Vue store auto-fill).
4. Étape Accommodations & Activities : assignation chambre, options, activités optionnelles.
5. Étape Confirmation : prix calculé via BookingService.GetCostPerPassenger.
6. Sauvegarde : BookingController.Create([FromBody] BookingDto) ou Pages/Bookings/CreateUpdate.OnPost selon le canal.
7. Si paiement immédiat (registerPayment=true) : création Payment + facture Confirmation (acompte) → statut Confirmed. Sinon le booking reste en Draft.

4. Réservation web/mobile (API)

1. Site web ou app mobile crée un booking via POST /api/Booking avec paymentDepositOnly = true|false.
2. Booking créé en BookingStatus.PendingWebOrMobile avec TransactionId du paiement Saferpay/CembraPay initialisé.
3. Le client paie côté Saferpay/CembraPay (montant = acompte si paymentDepositOnly=true, sinon total).
4. Worker (1 minute) IOnlinePaymentService.CheckPendingPayments :
   • Interroge Saferpay/CembraPay pour le statut.
   • Si succès : capture transaction, crée Payment, crée Invoice (Confirmation si deposit only, Simple ou Balance si total), bascule statut → Confirmed ou Billed, envoie email confirmation.
   • Si échec/timeout : marque comme tel, le booking peut être supprimé.
5. Important : le site web doit lire Travel.DepositPercentage via API et NE PAS hardcoder un pourcentage (cf. business-rules).

5. Génération facture & sync NAV

1. Booking passe en Confirmed → BillService génère Invoice de type Confirmation (acompte).
2. Plus tard, passage en Billed → génère Invoice Balance (solde).
3. Pour chaque facture émise :
   • Génération PDF via PdfGeneratorService (templates Liquid Confirmation.liquid, Balance.liquid, etc. + QrBillConfirmationBalance.liquid).
   • Post vers NAV/BC : NavSalesInvoiceService.CreateAsync puis NavPostDocument pour poster ; le NavNo revient et est stocké sur l'Invoice.
4. Encaissement : à chaque Payment, post vers NAV via NavPaymentService.
5. Toutes les factures partent en BC (Confirmation, Balance, Simple, Cancellation, CancellationInsurance, BuchardPart, Compensation).

6. Annulation booking

1. Commercial déclenche annulation via Pages/Bookings/Cancel (SPA cancel-booking).
2. Choix de la CancellationAction (frais retenus, remboursement total, transfert à l'assurance…).
3. Création Invoice Cancellation (frais Buchard) et/ou CancellationInsurance (transmission à l'assurance).
4. Si remboursement : création Payment négatif et post NAV.
5. Booking passe en Canceled. Si annulation partielle (certains passagers seulement), Booking.Status reste actif et les BookingPassenger annulés ont Cancelled = true.

7. Constitution dossier chauffeur

1. Quelques jours avant le départ, l'exploitation va dans Pages/LoadingTables.
2. Sélection des occurrences à grouper, création/édition d'un LoadingTable (avec Returns = false pour aller).
3. Sync VP : les chauffeurs/hôtesses du voyage sont récupérés depuis Visual Planning (lus via VisualPlanningService.GetTravelDriversAndHostsByOccurrence).
4. Ajout manuel de LoadingTableEntry (= petits cars de chargement par région). Les chauffeurs de chargement VP sont remplis automatiquement à partir de editables[1..] (la première ligne reçoit le chauffeur du voyage principal).
5. Saisie horaires aux Stop (surcharge des Timetable par défaut via LoadingTableTimetableStop).
6. Export Excel DriverFolder (Pages/LoadingTables/DriverFolder) → liste passagers + plan véhicule + horaires + tableau de chargement.

8. Sync Visual Planning daily

Worker.DoDailyJob > VisualPlanningService.SyncHostsAndDrivers :

1. Interroge l'API VP pour la liste des collaborateurs actifs.
2. Pour chacun, met à jour ou crée la Resource correspondante (mapping VisualPlanningId).
3. CustomerService.CleanGuestCustomers purge les comptes guest sans booking/gift/membership rattaché.

9. Bon cadeau : émission

Voie back-office Horizon

1. Commercial ouvre Pages/Gifts/Create.
2. Saisit montant, émetteur, bénéficiaire.
3. Sauvegarde → création Gift + facture (catégorie Gift).
4. Encaissement (en bureau ou via lien CB).
5. Pas d'envoi email auto. L'agent imprime / envoie manuellement.

Voie web/mobile

1. Achat sur le site → création Gift + paiement Saferpay/CembraPay.
2. Worker valide le paiement (1 minute).
3. Email envoyé automatiquement au bénéficiaire avec le bon (et envoi physique si IncludeEnvelope).

10. Bon cadeau : utilisation (encaissement)

1. Bénéficiaire utilise son bon lors d'une réservation.
2. Le bon est appliqué partiellement ou totalement sur l'Invoice.
3. Si solde restant : Gift.RemainingValue est mis à jour, le bon reste utilisable.

11. Adhésion Club Buchard

Émission

1. Création de la membership via Pages/SettingsXxx/... ou via web (souscription en ligne).
2. Facture InvoiceCategory.Membership (ou MembershipRenew).
3. Customer.ClubMembershipType mis à jour (Single ou Couple).
4. Customer.PaymentType stocke ici le moyen de paiement utilisé pour la souscription (uniquement).

Renouvellement annuel

1. Notifications de renouvellement (à confirmer côté équipe).
2. Si souscrit en ligne, paiement Saferpay/Cembra → facture MembershipRenew.

12. Auth client final (site web/mobile)

1. Login via Areas/Api/LoginController (POST email + password).
2. AuthService valide le password (BCrypt + fallback WordPressPasswordHasher pour les anciens comptes migrés).
3. Génération JWT + CustomerRefreshToken persisté.
4. Client utilise le JWT pour les requêtes API ultérieures ([Authorize(Policy = "Api")]).
5. Refresh token utilisé pour renouveler le JWT.

13. Auth back-office (utilisateur Buchard)

1. Login via Areas/Identity/Account/Login.
2. Cookie d'authentification ASP.NET Identity.
3. DefaultPolicy exigée sur tous les Razor Pages, AuthorizeFolder("/", "DefaultPolicy") automatique.

14. Auth back-office avec 2FA (TOTP)

Login avec 2FA déjà activé

1. Email + mot de passe sur /Identity/Account/Login.
2. Le SignInManager retourne RequiresTwoFactor → redirection vers /Identity/Account/LoginWith2fa.
3. Saisie du code à 6 chiffres de l'app d'authentification (TwoFactorAuthenticatorSignInAsync). En secours : LoginWithRecoveryCode (code de récupération à usage unique).

Date butoir et activation

1. Date butoir fixe en config : TwoFactor:SetupDeadline (appsettings, yyyy-MM-dd, UTC), identique pour tous.
2. Avant la date : accès normal + bannière de rappel (dans _Layout) invitant à configurer le 2FA.
3. L'utilisateur active quand il veut via /Identity/Account/Manage/EnableAuthenticator : scan du QR (clé otpauth rendue client-side), vérification d'un code, génération de 10 codes de récupération (ShowRecoveryCodes) puis retour à /.
4. À partir de la date sans 2FA : Enforce2faMiddleware force la redirection vers la page d'activation, aucune autre page accessible (mécanique identique à RedirectPendingUserMiddleware).

Exemptions & reset

• Comptes Microsoft SSO (IsMicrosoftAccount) : jamais soumis au 2FA applicatif (MFA géré par Azure AD).
• En cas de perte du téléphone : recovery codes, ou reset par un admin depuis la modale d'édition utilisateur (/Users/ResetTwoFactor) qui désactive le 2FA et réinitialise la clé (la date butoir fixe s'applique ensuite).

Contributors

No contributors

Changelog

No recent changes