+ ticketing and complexity
This commit is contained in:
parent
0d79ba89a6
commit
0893805ac4
1 changed files with 0 additions and 2 deletions
|
|
@ -138,11 +138,9 @@ Dans le cas des arrhes, à tout moment, jusqu'avant la date et l'heure de la pre
|
||||||
|
|
||||||
## Limitations
|
## Limitations
|
||||||
|
|
||||||
* **Aujourd'hui** : une prestation par commande, sur un axe client → prestataire unique, sans sous-traitance. **Cible roadmap** : montages multi-parties (plusieurs clients et/ou plusieurs fournisseurs collaborant autour d'un même projet, avec sous-traitance validée par le client) — voir la [ROADMAP](../ROADMAP.md).
|
|
||||||
* **Annulation : partielle et non testée.** Côté client, `HairCutCommandController.ClientCancel` / `ClientCancelConfirm` supprime la commande **sans déclencher de refund PayPal** ni logique arrhes vs avance ; aucune action d'annulation côté prestataire. La description du README (arrhes +20%, avance non-annulable) **n'est pas implémentée**. Cible : câbler `RefundTransaction` et le workflow complet, voir [ROADMAP](../ROADMAP.md).
|
* **Annulation : partielle et non testée.** Côté client, `HairCutCommandController.ClientCancel` / `ClientCancelConfirm` supprime la commande **sans déclencher de refund PayPal** ni logique arrhes vs avance ; aucune action d'annulation côté prestataire. La description du README (arrhes +20%, avance non-annulable) **n'est pas implémentée**. Cible : câbler `RefundTransaction` et le workflow complet, voir [ROADMAP](../ROADMAP.md).
|
||||||
* **Réclamation post-prestation : aucun support applicatif.** Passée la date de la prestation, le client n'a aucun chemin dans l'UI pour signaler un litige — aucune route, aucun contrôleur, aucun modèle. La fonctionnalité de conciliation est planifiée au **Jalon 5** (cf. [doc/ddd-exploration-2026-06-14.md](../doc/ddd-exploration-2026-06-14.md)) : double vue client/prestataire, dossier de conciliation, décision. En attendant, tout passe par e-mail au propriétaire de l'installation.
|
* **Réclamation post-prestation : aucun support applicatif.** Passée la date de la prestation, le client n'a aucun chemin dans l'UI pour signaler un litige — aucune route, aucun contrôleur, aucun modèle. La fonctionnalité de conciliation est planifiée au **Jalon 5** (cf. [doc/ddd-exploration-2026-06-14.md](../doc/ddd-exploration-2026-06-14.md)) : double vue client/prestataire, dossier de conciliation, décision. En attendant, tout passe par e-mail au propriétaire de l'installation.
|
||||||
* **Paiement : PayPal uniquement, via l'API NVP/SOAP.** Aucun autre PSP n'est intégré (pas de Stripe, pas d'Adyen). L'API NVP/SOAP que PayPal a dépréciée au profit de REST reste fonctionnelle mais n'est plus recommandée par PayPal ; aucune migration n'est planifiée à court terme.
|
* **Paiement : PayPal uniquement, via l'API NVP/SOAP.** Aucun autre PSP n'est intégré (pas de Stripe, pas d'Adyen). L'API NVP/SOAP que PayPal a dépréciée au profit de REST reste fonctionnelle mais n'est plus recommandée par PayPal ; aucune migration n'est planifiée à court terme.
|
||||||
* **Périmètre métier étroit.** Pas de saisie de structures de projets complexes ; pas de ticketing associé à la prestation.
|
|
||||||
* **Collecte centralisée.** Tous les paiements PayPal transitent par le compte du propriétaire de l'installation — c'est le seul identifiant configuré côté PSP. Les professionnels apparaissent comme tierces parties du point de vue PayPal.
|
* **Collecte centralisée.** Tous les paiements PayPal transitent par le compte du propriétaire de l'installation — c'est le seul identifiant configuré côté PSP. Les professionnels apparaissent comme tierces parties du point de vue PayPal.
|
||||||
* **Pas de gestion de paie.** Aucune édition de fiche de paye, ni paiement en masse. Seuls les paiements unitaires sus-cités sont supportés.
|
* **Pas de gestion de paie.** Aucune édition de fiche de paye, ni paiement en masse. Seuls les paiements unitaires sus-cités sont supportés.
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue