81 lines
3.6 KiB
Markdown
81 lines
3.6 KiB
Markdown
# Workflow maintenance external — proposition Phase 2.1
|
||
|
||
## État réel actuel
|
||
|
||
`LotTask` possède déjà `contrat`, `company_id`, `contract_id`,
|
||
`gestionnaire`, `periodicite` et `jours_entre_interventions`. `ScheduledTask`
|
||
possède également l’entreprise, le contrat, l’équipement, la salle,
|
||
l’affectation et les dates prévues/réelles. `ContractVisit` représente une
|
||
visite de contrat avec une date et un statut.
|
||
|
||
Cette base permet d’associer une tâche à une entreprise, mais ne distingue pas
|
||
encore proprement : date d’échéance, rendez-vous avec heure, passage libre,
|
||
arrivée réelle, non-venue et temps d’accompagnement du technicien.
|
||
|
||
## Parcours métier proposé
|
||
|
||
1. Dans la fiche du lot, choisir l’exécutant : technicien du collège,
|
||
entreprise, Département ou mixte.
|
||
2. Si nécessaire, choisir l’entreprise et le contrat.
|
||
3. Définir le périmètre : tous les équipements actifs du lot/catégorie, ou une
|
||
sélection manuelle filtrée par bâtiment, zone et salle.
|
||
4. Définir la périodicité et la prochaine échéance séparément.
|
||
5. Choisir le mode de passage : rendez-vous, date sans heure ou passage libre.
|
||
6. Pour un rendez-vous, saisir date, heure/durée, notes et accompagnement.
|
||
7. À l’arrivée, enregistrer le passage réel ; une non-venue laisse la tâche à
|
||
réaliser et permet de proposer un nouveau rendez-vous.
|
||
|
||
## États métier proposés
|
||
|
||
`À planifier`, `Rendez-vous fixé`, `Passage libre`, `Arrivée`, `En cours`,
|
||
`Réalisé`, `Reporté`, `Non venue`, `Annulé`.
|
||
|
||
Le rendez-vous et le passage réel sont distincts. La prochaine échéance ne doit
|
||
être recalculée qu’après une vérification réellement enregistrée, selon les
|
||
règles du contrat. Par défaut, la proposition est : date réelle + périodicité.
|
||
|
||
## Temps d’entreprise et temps technicien
|
||
|
||
La durée de présence de l’entreprise n’est pas automatiquement la durée
|
||
bloquée dans `DayPlanner`. Une tâche doit distinguer :
|
||
|
||
- présence totale de l’entreprise ;
|
||
- accompagnement ponctuel du technicien ;
|
||
- accompagnement complet du technicien.
|
||
|
||
Seul l’accompagnement prévu bloque l’agenda du technicien. Un passage libre
|
||
reste une information/alerte et ne réserve aucun créneau arbitraire.
|
||
|
||
## Périmètre des équipements
|
||
|
||
Deux modes sont à prévoir :
|
||
|
||
- **dynamique** : tous les équipements actifs répondant au lot/catégorie et
|
||
aux filtres de localisation ;
|
||
- **manuel** : sélection explicite d’équipements.
|
||
|
||
Le mode dynamique simplifie la maintenance d’un parc qui évolue ; le mode
|
||
manuel convient à un contrat limité à quelques appareils. L’interface doit
|
||
afficher le nombre d’équipements concernés et permettre de revoir la sélection.
|
||
|
||
## Espaces verts
|
||
|
||
Les durées de tonte, bordures, taille et évacuation sont des durées propres à
|
||
une zone. Elles ne doivent pas être portées par une règle générique de lot.
|
||
Une extension dédiée de périmètre/zone est à concevoir après validation du
|
||
modèle de localisation existant.
|
||
|
||
## RBAC et sécurité
|
||
|
||
La consultation suit les permissions du lot, de l’entreprise et du planning.
|
||
La modification d’un contrat ou d’un rendez-vous doit être autorisée par la
|
||
permission métier correspondante. Les liens vers les équipements restent
|
||
protégés par les permissions patrimoine.
|
||
|
||
## Migration à étudier avant développement
|
||
|
||
Avant toute migration, comparer une extension de `LotTask`/`ContractVisit` avec
|
||
un modèle de passage séparé. Les champs éventuels seraient notamment : mode
|
||
d’exécutant, mode de passage, fenêtre, heure, durée d’accompagnement, statut,
|
||
date réelle et périmètre dynamique. Aucune table ni migration n’est créée dans
|
||
cette étude.
|