Membres actuels

⚠️ À lire en premier

L'outil de création de devis (index.html) a été long et difficile à mettre au point — ne pas le casser. Toute refonte doit conserver ce fonctionnement exact ou faire une migration propre. Le dashboard (dashboard.html) communique avec index.html via postMessage car Safari file:// isole le localStorage par fichier.

📅 1 — Calendrier partagé (abonnement iCal)

Objectif : Quand une location est confirmée, elle apparaît automatiquement dans le Calendrier Apple de Rémi.

Comment : Apple Calendrier supporte l'abonnement à une URL .ics — il suffit d'une route GET /calendar.ics?token=xxx qui génère un iCalendar RFC 5545 avec un VEVENT par location à venir (DTSTART, DTEND, SUMMARY = client + pack, LOCATION = lieu, DESCRIPTION = prix + statut + contact). Rafraîchissement automatique toutes les heures.

📥 2 — Formulaire de réservation public → dashboard

Flux :
① Client remplit le formulaire (nom, email, tel, date, lieu, pack envisagé)
② La demande apparaît en haut de la page Locations sous forme de notification "📥 Demande à traiter"
③ Rémi clique Accepter → onglet Devis s'ouvre avec tous les champs pré-remplis
④ Rémi ajuste si besoin → génère le PDF → location auto-ajoutée à la liste
⑤ Rémi clique Refuser → archivé comme "Refusé"

Note technique : Le pré-remplissage est déjà codé dans index.html via prefillDevisFromLocation(loc) qui écoute postMessage({type:'ls64_open_devis', location:{...}}). Il suffit d'appeler ça depuis le dashboard.

✏️ 3 — Modifier une location depuis le tableau

Déjà partiellement implémenté : Les locations à venir ont un bouton ✏️ bleu qui ouvre l'onglet Devis et pré-remplit le formulaire via openInDevis(locId).

À compléter : recalculer le forfait km selon le lieu lors du pré-remplissage. Après modification, si le num_devis reste le même, la ligne se met à jour automatiquement (déduplication par num_devis déjà en place).

📧 4 — Envoi automatique du reçu par mail (Remise matériel)

Contexte : Lors de la remise du matériel au client, l'employé coche la liste + le client signe sur l'écran → un reçu (PDF) + la charte de location doivent être envoyés automatiquement à l'adresse email du client.

Problème : L'app tourne en pur HTML/JS côté client — impossible d'envoyer un mail sans serveur.

Solution recommandée : EmailJS
→ Service gratuit jusqu'à 200 mails/mois
→ S'intègre en JS pur : emailjs.send(serviceId, templateId, params)
→ Supporte les pièces jointes base64 (pour envoyer le PDF)
→ Clé publique à placer dans l'app : emailjs.init("YOUR_PUBLIC_KEY")

À configurer sur emailjs.com :
① Créer un compte (email : remi.renard64@gmail.com)
② Connecter le service email (Gmail)
③ Créer un template "recu_location" avec les variables : {{to_email}} {{prenom}} {{pack}} {{date}} {{caution}}
④ Récupérer : Service ID + Template ID + Public Key → les injecter dans l'app

En attendant : L'app utilise un lien mailto: qui ouvre Mail avec le corps pré-rempli — l'utilisateur doit appuyer sur Envoyer manuellement. Remplacer par EmailJS dès que la clé est dispo.

🏗 5 — Architecture recommandée

Navigation : Locations (principale) → Nouveau devis → Demandes (réservations) → Répartition

Stack suggérée : Next.js + Prisma + SQLite (simple à héberger) ou FastAPI + SQLite. Auth : login email/mdp pour protéger le dashboard.

Champs d'une location : id, date, year, month, client, prenom, email, tel, pack, pack_id, categorie, prix_pack, deplacement, total, caution, lieu, statut (en_attente/a_venir/termine/refuse), paiement (non_paye/acompte_verse/solde_paye), num_devis, client_type

Clés localStorage actuelles à migrer en DB : ls64_dyn_locations, ls64_hist_overrides, ls64_settings, ls64_custom_packs