Règles métier DYCE Work Order

1. Introduction

Objectif

La référence qui fait foi pour le comportement des Work Orders, des lignes Work Order et des enregistrements de temps, ainsi que pour leurs contraintes mutuelles. Elle indique ce qui est autorisé, ce qui est interdit et — lorsque ce n'est pas évident — pourquoi.

Public cible

Développeurs et intégrateurs qui implémentent ou déboguent le comportement des Work Orders dans DYCE Connect, Business Central et les systèmes connectés (Jira, Azure DevOps).

Périmètre

Ces règles sont indépendantes de la plateforme : elles s'appliquent quelle que soit l'interface utilisée. Les règles qui ne s'appliquent qu'à un seul système sont marquées (Jira), etc.

Comment lire ce document

Presque chaque règle est une condition de garde portant sur le même petit état. Le document est donc construit de bas en haut :

• §3 État définit ce qu'est un Work Order — les données sur lesquelles opère chaque règle.
• §4 Invariants sont les propriétés toujours vraies. Elles sont énoncées une seule fois et référencées partout ailleurs par leur nom ; la principale est le verrou structurel.
• §5 Opérations est la référence de travail : chaque modification possible, toujours présentée de la même façon — Garde (quand elle est bloquée ou requise), Effet (ce qui change) et Pourquoi lorsque ce n'est pas évident. Il suffit d'y rechercher l'opération à effectuer.
• §6–8 traitent du comportement de facturation, de la réservation et des tableaux de référence rapide.

Les règles sont nommées, pas numérotées. (Les versions antérieures les numérotaient X.Y ; cet index est conservé dans l'annexe à titre historique uniquement.)

2. Glossaire

Terme	Abréviation	Définition
Work Order	WO	Unité de travail distincte qui peut être suivie, budgétée et facturée
Billing Work Order	BWO	Le Work Order qui sert de point d'agrégation pour la facturation. Le temps et les coûts des Work Orders associés sont regroupés à ce niveau
Sub-Work Order	Sub-WO	Un Work Order qui référence un autre Work Order comme BWO
Projet	-	Conteneur pour le travail planifié, lié à un client (nom technique dans BC : "Job")
Tâche projet	PT	Unité de travail au sein d'un projet (nom technique dans BC : "Job Task")
Ligne de planification de projet	PPL	Ligne d'affectation de budget au sein d'une tâche projet. Existe en deux types : budget (planifié) et facturable (réel)
Écriture comptable projet	PLE	Enregistrement créé lors de la validation et/ou de la facturation d'enregistrements de temps
Ligne Work Order	WOL	Enregistrement qui relie un Work Order à une ligne de planification de projet et définit le budget disponible pour ce Work Order
Enregistrement de temps	TR	Enregistrement du temps réellement consacré au travail
Activité	-	Le type de travail effectué (par exemple conseil, développement, test). Dérivé du modèle Time & Travel
Type de budget	-	Paramètre du Work Order qui détermine la rigueur avec laquelle les lignes Work Order sont imposées : "Ouvert" ou "Projet"
Type de facturation de la prestation	-	Mode de facturation d'une ligne Work Order : "Sur base du temps et matériel", "Budget" ou "Prix fixe"
Organisation	-	Représentation externe d'un client dans les systèmes de gestion des services (par exemple Jira Service Management)
Actif	-	Représentation pouvant être liée de clients, de contrats ou de projets dans des systèmes externes

3. État — ce qu'est un Work Order

Chacune des règles ci-dessous est une fonction de cet état.

Customer
  └── Project
        └── Project Task (PT)
              └── Project Planning Line (PPL)   ← the budget

Work Order
  ├── Billing Work Order   → itself, or one other WO (the BWO)
  ├── Budget Type          → Open | Project
  ├── Customer / Project    (owned by the BWO — see BWO Ownership)
  ├── Work Order Lines     → each links the WO to one PPL
  └── Time Recordings      → each records effort against a PPL; status Open|Released|Posted

Un Work Order est un lot de travail distinct. Son Billing Work Order est soit lui-même (un WO autonome/de facturation), soit un autre Work Order par lequel il est facturé (ce qui en fait un Sub-WO). Un groupe de facturation se compose d'un BWO et des Sub-WOs qui pointent vers lui.

Les lignes Work Order relient le WO à des lignes de planification de projet et définissent le budget qu'il peut consommer. Les enregistrements de temps saisissent l'effort réel sur une PPL et passent par trois statuts :

Statut	Signification	Modifiable	Supprimable
Ouvert	Brouillon / pas encore approuvé	Oui	Oui
Libéré	Approuvé pour la facturation, quantité calculée	Non (réouverture uniquement)	Non
Validé	Traité financièrement, écritures comptables créées	Non (annulation uniquement)	Non

Chaque étape représente un engagement financier plus fort et réduit la flexibilité.

Type de budget

Le type de budget détermine la rigueur avec laquelle les enregistrements sont liés aux lignes du Work Order :

• Ouvert — flexible. Un enregistrement peut utiliser n'importe quelle PT/PPL du projet du WO ; si sa PPL n'a pas encore de ligne, une ligne est créée automatiquement. Pour le travail réactif dont le budget n'est pas connu à l'avance (tickets de support, demandes ponctuelles).
• Projet — strict. Un enregistrement peut uniquement utiliser des PT/PPL qui ont déjà une ligne Work Order ; les recherches sont filtrées sur celles-ci et, en l'absence de lignes, les champs PT/PPL sont désactivés. Pour le travail planifié avec un budget préalablement affecté (projets de mise en œuvre, commandes vente). Ne peut être défini qu'une fois un client et un projet affectés.

4. Invariants

Propriétés toujours vraies. Énoncées une seule fois ici ; référencées par leur nom dans toute la section §5.

Propriété du BWO

Le BWO détient le client, le projet et le type de budget pour l'ensemble de son groupe de facturation. Un Sub-WO reprend ces trois champs de son BWO et ne peut pas les remplacer directement ; leur modification sur le BWO est répercutée sur chaque Sub-WO. Le groupe de facturation reste ainsi facturable comme une unité — un client, un projet, un mode de contrôle pour l'ensemble.

Lignes du BWO

Les lignes Work Order résident sur le BWO. Le BWO détient l'ensemble maître ; les lignes d'un Sub-WO en sont un sous-ensemble, chacune référençant sa ligne maître du BWO. Un Sub-WO ne peut jamais détenir une ligne absente de son BWO — il ne peut pas revendiquer un budget que le BWO n'a pas affecté. L'affectation d'une ligne du BWO à un Sub-WO est un acte délibéré, jamais automatique.

Hiérarchie plate

Le BWO d'un Work Order est lui-même ou exactement un vrai BWO — jamais plus profond, jamais une boucle.

Configuration	Autorisée
WO-01 → WO-01 (lui-même)	Oui
WO-01 → WO-02, WO-01 → WO-03 (un niveau)	Oui
WO-01 → WO-02 → WO-03 (deux niveaux d'indirection)	Non (imbrication)
WO-01 → WO-02, WO-02 → WO-01	Non (boucle)

Un BWO utilisé par des Sub-WOs doit être son propre BWO (corollaire de la limite à deux niveaux). Des hiérarchies plus profondes compliquent la facturation ; des boucles feraient apparaître deux fois le même enregistrement dans Project Billing.

Le verrou structurel

Les enregistrements de temps existants empêchent de restructurer un Work Order sous leurs pieds. Il régit quatre opérations : Modifier le Billing Work Order, Modifier le client ou le projet, Supprimer un Work Order et Supprimer une ligne Work Order.

Dès que des enregistrements existent, les modifications qui les rendraient orphelins ou les achemineraient mal — ou qui supprimeraient le budget auquel ils sont rattachés — sont bloquées. La rigueur dépend du type de budget et du statut le plus avancé parmi les enregistrements, vérifié sur l'ensemble du groupe de facturation (les lignes ci-dessous correspondent au statut le plus avancé présent) :

Statut de l'enregistrement de temps	Budget Ouvert	Budget Projet
Aucun	autorisé	autorisé
Ouvert	autorisé	bloqué
Libéré / Validé	bloqué	bloqué

Une opération est plus stricte que le tableau : Supprimer une ligne Work Order est bloquée par tout enregistrement dans les deux types de budget — car un enregistrement Ouvert ne peut pas être libéré sans sa ligne si la validation par Work Order est activée (Oui). Le tableau régit les trois autres.

Pourquoi il existe : les enregistrements libérés et validés ont été approuvés et validés pour un client, un projet et une agrégation de facturation précis ; les opérations contrôlées les achemineraient vers une destination pour laquelle ils n'ont jamais été approuvés, ou les couperaient de la ligne de budget qui porte leur quantité à facturer. Avec le type de budget Projet, le lien est total — les enregistrements doivent utiliser le client, le projet et les lignes du Work Order — de sorte que même un enregistrement Ouvert fige la structure. Avec le type de budget Ouvert, ce lien n'existe pas (les enregistrements peuvent s'écarter de l'en-tête) ; seuls les enregistrements libérés/validés, qui portent un engagement financier, verrouillent quelque chose.

5. Opérations

Chaque opération indique sa Garde (quand elle est bloquée ou requise), son Effet (ce qui change) et le Pourquoi lorsque ce n'est pas évident.

5.1 Work Orders

Créer un Work Order

• Effet (universel, dans les deux systèmes) — un Work Order créé sans référence à un Billing Work Order devient son propre BWO (autonome) ; un Work Order créé avec une référence devient un Sub-WO de ce BWO. Dans les deux cas, il est prêt à porter des lignes et des enregistrements.
• (Jira) Juste-à-temps + BWO automatique. C'est ainsi que Jira déduit cette référence. Les Work Orders ne sont créés qu'en cas de besoin — déclenchés par un enregistrement sur un Work Item ou par un budget affecté à un Work Item. Lors de la création, la hiérarchie est parcourue vers le haut (tâche → story → epic) jusqu'au premier parent correspondant au "Billing Work Order Type" configuré : ce parent devient le BWO ; si aucun Work Item supérieur ne correspond, le Work Order devient son propre BWO. (Les autres systèmes fournissent directement la référence au lieu de la déduire de cette façon.)
• (Jira) Les Work Orders existants conservent leur BWO. L'affectation automatique du BWO n'a lieu qu'à la création. La hiérarchie des Work Items continue d'arriver lors des synchronisations ultérieures, mais pour un Work Order qui existe déjà, elle n'est pas réappliquée — un processus automatique ne peut donc pas écraser un BWO défini manuellement par un utilisateur. Après la création, seule une modification explicite du BWO déplace le BWO.

Modifier le Billing Work Order

(modifier le WO par lequel celui-ci est facturé)

• Garde (toujours) — trois blocages indépendants ; tous doivent être levés :

  1. Pas un BWO utilisé. Un Work Order qui sert de BWO à d'autres ne peut pas changer de BWO (ses Sub-WOs deviendraient orphelins).
  2. La cible est un vrai BWO. La cible doit être son propre BWO, ce qui préserve la hiérarchie plate.
  3. Pas verrouillé par des enregistrements (verrou structurel) — bloqué dès qu'un WO en mode Projet a un enregistrement quelconque, ou qu'un WO en mode Ouvert a un enregistrement libéré/validé.

  La modification du BWO a deux points de départ, qui diffèrent dans le traitement des lignes :

  • Déplacement d'un Sub-WO vers un autre BWO. Ses lignes ne lui appartiennent pas — elles référencent les lignes maîtres de l'ancien BWO (lignes du BWO) — le déplacement les supprime donc toutes. Une ligne qui porte un enregistrement ne peut pas être supprimée (Supprimer une ligne Work Order) ; le déplacement est donc en outre bloqué tant que l'une de ses lignes porte un enregistrement, même Ouvert.
  • Rétrogradation d'un BWO autonome en Sub-WO. Ses lignes sont ses propres lignes maîtres : les lignes sans enregistrement sont supprimées, les lignes avec enregistrements sont conservées.

• Effet (dans les deux cas) — le client, le projet et le type de budget sont hérités du nouveau BWO (propriété du BWO) ; le changement de projet hérité se comporte comme Modifier le client ou le projet. Les enregistrements non validés sont désormais facturés par le nouveau BWO.

Modifier le client ou le projet

• Garde — deux blocages indépendants :
  1. Pas verrouillé par des enregistrements (verrou structurel) — type de budget Projet : bloqué dès qu'un enregistrement quelconque existe dans le groupe de facturation (pas encore de réaffectation automatique en mode Projet — les enregistrements doivent d'abord être déplacés ou supprimés). Budget Ouvert : jamais bloqué — le client/projet peut être défini, effacé ou modifié à tout moment.
  2. Le projet nécessite un client donneur d'ordre. Un projet ne peut être sélectionné que s'il en a un (sinon il ne peut pas être facturé).
• Effet
  • Sur un BWO, la modification est répercutée sur tous les Sub-WOs (propriété du BWO) ; le client/projet d'un Sub-WO est en lecture seule et ne peut changer que de cette façon (ou en modifiant le BWO du Sub-WO).
  • La modification/l'effacement du client efface le projet ; si le nouveau client a exactement un projet actif (statut ≠ Terminé), celui-ci est sélectionné automatiquement. La sélection d'un projet définit le client ; l'effacement du client efface le projet.
  • La modification du projet met automatiquement à jour vers le nouveau projet les enregistrements sans PT. Les enregistrements avec PT perdraient leur PT/PPL/activité ; l'utilisateur doit donc les corriger ; d'ici là, ils ne peuvent être ni libérés ni facturés, et l'ancienne WOL qu'ils référencent encore ne peut pas être supprimée (elle s'affiche en rouge).
• Pourquoi — en mode Projet, les enregistrements sont liés au client/projet du WO, de sorte que toute modification les invaliderait immédiatement ; en mode Ouvert, ce lien n'existe pas, la modification est donc toujours sûre et constitue le moyen prévu pour corriger une erreur.

Modifier le type de budget

• Garde
  • Ouvert → Projet : un client et un projet doivent être définis, et chaque enregistrement existant doit avoir une PPL correspondant à une ligne Work Order. Si ce n'est pas le cas pour certains, le système propose de créer automatiquement les lignes manquantes ; un refus annule la modification.
  • Projet → Ouvert : toujours autorisé — assouplir les contraintes ne peut pas invalider les données.
• Effet — sur un BWO, le type de budget est répercuté sur tous les Sub-WOs (propriété du BWO) ; un Sub-WO ne peut pas modifier directement son type de budget.

Supprimer un Work Order

• Garde — deux blocages indépendants ; les deux doivent être levés :
  1. Aucun Sub-WO dépendant. Un Work Order qui sert de BWO à d'autres ne peut pas être supprimé (ils deviendraient orphelins) — il faut d'abord supprimer ou réaffecter tous les Sub-WOs.
  2. Pas verrouillé par des enregistrements (verrou structurel) — budget Projet : bloqué dès qu'un enregistrement existe ; budget Ouvert : bloqué uniquement tant que des enregistrements libérés/validés existent (supprimable lorsque seuls des enregistrements Ouverts existent).
• Pourquoi — la suppression d'un Work Order avec des enregistrements engagés ferait perdre un travail approuvé et enregistré financièrement.

5.2 Lignes Work Order

Ajouter une ligne Work Order (sur un BWO)

• Garde — deux blocages indépendants :
  1. Uniquement sur un BWO. Les lignes sont créées sur le BWO, jamais directement sur un Sub-WO (lignes du BWO).
  2. PPL unique par Work Order. Une PPL peut figurer dans au plus une ligne par Work Order ; l'ajout d'une PPL déjà présente est refusé (évite le double comptage et la nécessité de choisir une ligne lors de l'enregistrement).
• Effet — la ligne existe désormais sur le BWO et peut être affectée à des Sub-WOs lors d'une étape distincte et délibérée (lignes du BWO).

Affecter une ligne à un Sub-WO

• Garde — seules les lignes qui existent sur le BWO parent peuvent être sélectionnées ("Get Work Order Line") ; il est impossible de créer une nouvelle ligne directement sur un Sub-WO (lignes du BWO).
• Effet — la ligne du Sub-WO référence sa ligne maître du BWO.

Supprimer une ligne Work Order

• Garde — bloquée tant qu'un enregistrement de temps quelconque référence (WO, PPL) — quel que soit le statut, quel que soit le type de budget (verrou structurel, forme stricte). Une ligne de prestation additionnelle est protégée de la même façon.
• Effet
  • La suppression d'une ligne du BWO est répercutée : les lignes correspondantes de tous les Sub-WOs sont également supprimées (les Sub-WOs ne doivent pas conserver de références fantômes à un budget supprimé).
  • La suppression d'une ligne d'un Sub-WO la retire uniquement de ce Sub-WO ; elle reste sur le BWO et les autres Sub-WOs.
• Pourquoi — un enregistrement Ouvert ne peut pas être libéré sans sa ligne ; les enregistrements libérés/validés portent un historique financier qui doit être préservé. (Plus strict que Supprimer un Work Order, qui permet de supprimer un WO à budget Ouvert n'ayant que des enregistrements Ouverts.)

5.3 Enregistrements de temps

Enregistrer du temps (création)

• Garde / comportement selon le type de budget
  • Ouvert : l'enregistrement doit utiliser le client et le projet du WO (s'ils sont renseignés). Si le WO n'a pas de client/projet, le premier enregistrement qui les porte les définit sur le WO, et les autres enregistrements vides sont complétés automatiquement. Un enregistrement dont la PPL n'a pas de ligne crée automatiquement la ligne.
  • Projet : l'enregistrement doit utiliser une PT/PPL qui correspond à une ligne Work Order existante, sinon il ne peut pas être enregistré. Si un Sub-WO a au moins une ligne propre, l'enregistrement doit utiliser l'une de celles-ci ; seul un Sub-WO sans ligne propre se rabat sur les lignes du BWO.
• Effet
  • La sélection d'une PT préremplit l'activité de l'enregistrement avec la valeur par défaut de la ligne correspondante (toujours modifiable).
  • Une prestation additionnelle peut être sélectionnée que sa ligne existe déjà ou non — l'enregistrement crée automatiquement la ligne (dans les deux types de budget).
  • (Jira / Azure DevOps) Le client/projet (et d'autres informations) peuvent être affectés à partir de l'espace, de l'organisation, du client ou de l'actif ; un enregistrement utilisant une telle affectation crée le WO avec les informations affectées.
• Pourquoi — le mode Ouvert réduit au minimum le paramétrage pour le travail réactif ; le mode Projet garantit que tout le temps peut être suivi par rapport au budget préalablement affecté. Le client/projet a des implications financières (modèle Time & Travel, client facturé, majorations) ; un enregistrement ne peut donc pas s'écarter de ceux du WO une fois définis.

Modifier le Work Order d'un enregistrement

• Vers un WO à budget Projet — le client/projet est mis à jour en conséquence ; les PT/PPL/activité existantes sont vérifiées par rapport aux lignes du nouveau WO et effacées si elles ne sont pas valides (l'utilisateur doit en choisir des valides).
• Vers un WO à budget Ouvert — le client/projet n'est mis à jour que s'il était vide ; si le nouveau WO a exactement une ligne et que les PT/PPL/activité de l'enregistrement sont vides, elles sont renseignées automatiquement.

Effacer le Work Order d'un enregistrement

• Effet — le client, le projet, la PT, la PPL et l'activité sont tous conservés ; seule l'association au Work Order est supprimée (le travail effectué reste valide).

Libérer

• Garde — un enregistrement avec un WO et une PPL ne peut être libéré que si une ligne Work Order correspondante existe ; une libération sans ligne génère une erreur. (En mode Ouvert, la ligne a déjà été créée automatiquement lors de l'enregistrement ; il s'agit donc d'un filet de sécurité.) Un Sub-WO sans ligne propre est libéré via les lignes du BWO.
• Effet — statut Ouvert → Libéré ; la durée facturable est ajoutée à la "Quantité à facturer" — sur la ligne Work Order lorsque l'enregistrement a un Work Order, ou sur la PPL (budget) lorsqu'il n'en a pas — avec application de l'arrondi du modèle Time & Travel.
• Pourquoi — la libération est l'étape d'approbation ; la quantité à facturer doit résider sur une ligne.

Valider

• Effet — statut Libéré → Validé, et les enregistrements financiers sont écrits :
  • Des écritures comptables projet (consommation) sont créées, avec enregistrement du N° de WO et de BWO.
  • Des PPL (facturables) sont créées/mises à jour ; lorsque la validation par Work Order est activée, une PPL (facturable) est créée par BWO et PPL (budget) — plusieurs Sub-WOs sur la même PPL sous un même BWO y sont agrégés (la facturation s'agrège au niveau du BWO).
  • La quantité à facturer est transférée des lignes Work Order / de la PPL (budget) vers la PPL (facturable) ; les lignes de commande vente sont mises à jour le cas échéant.
• Après la validation — le verrou structurel maintient la structure : pas de modification du BWO, pas de modification du client/projet sur un BWO à budget Projet, pas de suppression des lignes utilisées par des enregistrements validés. (Avec un budget Ouvert, le client/projet reste modifiable ; les enregistrements validés conservent leur projet et leurs écritures comptables ne sont pas affectées.) Ces enregistrements sont corrigés par une annulation, jamais en modifiant ce vers quoi ils pointent.

Annuler (un enregistrement validé)

• Effet — des écritures comptables projet (consommation) négatives et des PPL (facturables) négatives sont créées (à partir des positives) ; l'enregistrement revient au statut Ouvert et la quantité annulée redevient un budget disponible. Une piste d'audit complète est ainsi conservée.

6. Type de facturation service

Le type de facturation service d'une PPL détermine la façon dont son budget est consommé et facturé.

	Sur base du temps et matériel	Budget	Prix fixe
Quantité réservée par rapport au budget	peut être dépassée ; non mise à jour par la validation	peut être dépassée ; non mise à jour par la validation	peut être dépassée ; non mise à jour par la validation
Plafond de facturation	aucun — tout le temps facturable est facturé	la quantité de la PPL (budget) est un plafond strict	la quantité de la PPL (budget), facturée intégralement à l'achèvement
Validation au-delà du budget	la PPL (budget) augmente automatiquement ; les lignes vente suivent	autorisée, mais non facturée au-delà du plafond	autorisée, mais seule la quantité budgétée est facturée
Quantité à facturer	calculée à la libération (somme des durées facturables)	jusqu'au plafond	quantité totale à l'achèvement ; pas de facturation partielle

• Sur base du temps et matériel — travail continu ; le client paie l'effort réel.
• Budget — un plafond maximal ; le client paie jusqu'à une limite.
• Prix fixe — basé sur les livrables ; un montant fixe indépendamment de l'effort, facturé à l'achèvement. Les enregistrements suivent l'effort, mais ne déterminent pas la quantité facturée.

7. Réservation de budget

Une ligne Work Order peut réserver du budget exclusivement pour son Work Order.

• Une quantité réservée vide signifie que le Work Order partage le budget avec tous les autres (par exemple plusieurs Work Orders pour des ateliers/formations) ; la libération des enregistrements bloque alors du budget via la quantité à facturer, selon le principe du premier arrivé, premier servi.
• Une quantité réservée renseignée est bloquée pour le Work Order et limitée par la quantité sélectionnée — sauf pour Sur base du temps et matériel, qui peut augmenter (modifications logicielles, demandes de modification).
• La quantité réservée est facturée par le Work Order qui l'a réservée.
• La somme des quantités réservées peut dépasser le budget réel ; la quantité disponible est alors mise en évidence en rouge.

8. Référence rapide

Configurations de BWO valides

WO-A	BWO de A	WO-B	BWO de B	Valide ?
WO-01	WO-01	-	-	Oui (autonome)
WO-01	WO-02	WO-02	WO-02	Oui (hiérarchie simple)
WO-01	WO-02	WO-03	WO-02	Oui (WO de même niveau sous un BWO)
WO-01	WO-02	WO-02	WO-03	Non (imbrication)
WO-01	WO-02	WO-02	WO-01	Non (boucle)

Comparaison des types de budget

Aspect	Ouvert	Projet
Sélection de la PPL lors de l'enregistrement	toute PPL valide du projet	uniquement les PPL qui ont une ligne Work Order
Création automatique des lignes Work Order	Oui	Non
Suppression d'une WOL — aucun enregistrement	Oui	Oui
Suppression d'une WOL — enregistrement Ouvert	Non	Non
Suppression d'une WOL — Libéré/Validé	Non	Non

La suppression d'une WOL est bloquée par tout enregistrement dans les deux modes (forme stricte du verrou structurel).

Le verrou structurel en un coup d'œil

Ce que les enregistrements bloquent, selon le type de budget et le statut d'enregistrement le plus avancé présent (ensemble du groupe de facturation). Régit : Modifier le BWO, Modifier le client/projet, Supprimer un WO, Supprimer une WOL.

Statut de l'enregistrement de temps	Budget Ouvert	Budget Projet
Aucun	autorisé	autorisé
Ouvert	autorisé¹	bloqué
Libéré / Validé	bloqué	bloqué

¹ Sauf Supprimer une ligne Work Order, bloquée par tout enregistrement dans les deux modes.

Transitions de statut des enregistrements de temps

      ┌─────────────────────────────────┐
      │                                 │
      ▼                                 │
   [Open] ──release──► [Released] ──post──► [Posted]
      ▲                     │                  │
      │                     │                  │
      └────────reopen───────┘                  │
      │                                        │
      └─────────────cancel─────────────────────┘

Relations entre entités

Customer (1) ◄─────── (N) Project (1) ◄─────── (N) Project Task
                                                        │
                                                        ▼
                                              Project Planning Line
                                                        │
                                                        ▼
Work Order (N) ◄────────────────────────────────► Work Order Line
     │
     ▼
Billing Work Order (self or other WO)

9. Évolutions prévues

Pas encore appliqué.

Facturation par jalons (nécessite une analyse produit approfondie) — les enregistrements peuvent être validés sans déclencher de facturation automatique ; la facturation est suspendue jusqu'à ce qu'une condition de jalon soit remplie (par exemple Work Order marqué comme terminé) ; les travaux en cours (WIP) sont suivis pendant la suspension.

Addendum : synchronisation

Il s'agit d'un mécanisme, pas d'une règle métier — mais il détermine la façon dont les règles ci-dessus doivent être émises entre les systèmes ; il est donc consigné ici.

Les données des Work Orders sont synchronisées entre les systèmes (Connect, BC, Jira). Une modification ne constitue pas une transaction atomique : le système d'origine l'émet sous forme d'une séquence d'opérations portant chacune sur un seul champ, chacune contenant l'état complet de l'entité, et le destinataire exécute ses propres contrôles de règles métier sur chaque opération à son arrivée. Deux propriétés garantissent la sécurité de ce fonctionnement :

• Rejeu ordonné. Comme le destinataire traite chaque opération l'une après l'autre, l'ordre compte et chaque état intermédiaire doit être valide en soi. Le système d'origine doit ordonner les opérations de sorte que l'état redéduit par le destinataire corresponde, sans que celui-ci n'ait rien de propre à émettre. Exemples : les lignes doivent être créées avant que le type de budget passe de Ouvert à Projet ; un client doit être défini avant un projet ; une WOL n'est supprimée qu'après le déplacement de ses enregistrements vers le nouveau projet.
• Origine unique. Une modification qu'un système a reçue et appliquée — ainsi que toute autre modification produite par sa propre logique lors de cette application — ne doit jamais être renvoyée. Le destinataire accepte par principe la modification entrante comme faisant foi et l'applique sans la renvoyer à l'expéditeur. C'est précisément là que la réexécution de la logique locale à la réception est dangereuse : un effet secondaire de l'application d'une modification reçue peut ressembler à une nouvelle modification locale et être réémis — cette modification renvoyée est un écho, et un défaut. Le seul flux retour légitime est l'inscription par BC du N° de WO qu'il a attribué sur une création de Work Order entrante — ce N° provient réellement de BC ; son émission est donc conforme à cette règle et ne constitue pas une exception.

Les deux systèmes continuent d'appliquer leurs contrôles de règles métier à la réception — une modification reçue doit toujours être valide à son arrivée — mais ils ne rejouent pas les effets secondaires qui modifient les données. Les répercussions, élagages et lignes créées automatiquement qu'implique une modification sont calculés par le système d'origine et arrivent sous forme d'opérations distinctes ; redéduire ces modifications de données sur le destinataire est exactement ce qui crée un écho.

Ce qui est synchronisé : la synchronisation est pilotée par les modifications de données suivies, et non par une liste de déclencheurs établie — chaque création, mise à jour ou suppression d'une entité synchronisée est capturée et propagée. Connect → BC est piloté par l'audit (un SyncService ordonné) ; BC → Connect passe par une table de suivi. (Dans Jira, un Work Item ne devient un Work Order que lorsqu'il est modifié, mais il s'agit de la création juste-à-temps de Jira — voir Créer un Work Order — et non du déclencheur de synchronisation Connect↔BC.)

Annexe : index des anciens numéros de règle

À titre historique uniquement — ne pas utiliser ces numéros dans de nouveaux travaux. Les versions antérieures de ce document numérotaient les règles X.Y. Ce catalogue a été remplacé par les invariants et opérations nommés. Ce tableau associe chaque ancien numéro à l'emplacement actuel de son contenu, afin que les anciennes citations (dans d'autres documents ou dans le code) puissent être retrouvées et migrées. Les nouveaux renvois doivent pointer vers l'invariant ou l'opération par son nom.

Ancienne règle	Désormais dans
4.1 Deux niveaux max.	Hiérarchie plate
4.2 Pas de boucles	Hiérarchie plate
4.3 Pas d'imbrication	Hiérarchie plate
4.4 Modification du BWO contrôlée	Modifier le Billing Work Order
4.5 Configurations valides	Configurations de BWO valides
5.1 Le Sub-WO hérite du client/projet	Propriété du BWO
5.2 Le Sub-WO ne peut pas remplacer	Propriété du BWO · Modifier le client ou le projet
5.3 Répercussion sur les Sub-WOs	Propriété du BWO · Modifier le client ou le projet
5.4 Client/projet contrôlé	Modifier le client ou le projet
5.5 La modification du client efface le projet	Modifier le client ou le projet
5.6 Le projet nécessite un client	Modifier le client ou le projet
5.7 Projets sans client	Modifier le client ou le projet
5.8 Modification du projet / enregistrements	Modifier le client ou le projet
6.1 Le BWO détient l'ensemble maître	Lignes du BWO
6.2 La création ne copie pas	Ajouter une ligne Work Order
6.3 La suppression d'une ligne du BWO est répercutée	Supprimer une ligne Work Order
6.4 Le Sub-WO sélectionne parmi les lignes du BWO	Affecter une ligne à un Sub-WO
6.5 Suppression d'une ligne de Sub-WO	Supprimer une ligne Work Order
6.6 PPL une seule fois par WO	Ajouter une ligne Work Order
6.7 Suppression de WOL contrôlée	Supprimer une ligne Work Order
6.8 Les prestations additionnelles créent automatiquement des lignes	Enregistrer du temps
7.1 Comportement Ouvert	Type de budget · Enregistrer du temps
7.2 Comportement Projet	Type de budget · Enregistrer du temps
7.3 Ouvert → Projet	Modifier le type de budget
7.4 Projet → Ouvert	Modifier le type de budget
7.5 Répercussion du type de budget	Propriété du BWO · Modifier le type de budget
7.6 Le Sub-WO ne peut pas modifier le type de budget	Propriété du BWO · Modifier le type de budget
8.1 Cycle de vie des statuts	§3 État
8.2 Projet nécessite une ligne correspondante	Enregistrer du temps
8.3 Sub-WO Projet sans lignes	Enregistrer du temps
8.4 Ouvert complète automatiquement le client/projet	Enregistrer du temps
8.5 Ouvert limite au client/projet du WO	Enregistrer du temps
8.6 Ouvert crée automatiquement des lignes	Enregistrer du temps
8.7 Modification du WO d'un enregistrement → Projet	Modifier le Work Order d'un enregistrement
8.8 Modification du WO d'un enregistrement → Ouvert	Modifier le Work Order d'un enregistrement
8.9 L'effacement du WO conserve les champs	Effacer le Work Order d'un enregistrement
8.10 Activité par défaut issue de la ligne	Enregistrer du temps
8.11 Libéré/Validé bloque les modifications	Verrou structurel
9 Réservation de budget	§7 Réservation de budget
10.1 Sur base du temps et matériel	§6 Type de facturation service
10.2 Budget	§6 Type de facturation service
10.3 Prix fixe	§6 Type de facturation service
11.1 Création juste-à-temps	Créer un Work Order
11.2 Affectation automatique du BWO	Créer un Work Order
11.3 Les WOs existants conservent leur BWO	Créer un Work Order
11.4 Un BWO avec des Sub-WOs ne peut pas être supprimé	Supprimer un Work Order
11.5 Suppression de WO contrôlée	Supprimer un Work Order
12.1 Effet de la libération	Libérer
12.2 Ligne requise pour la libération	Libérer
12.3 Effet de la validation	Valider
12.4 PPL (facturable) par BWO	Valider
12.5 La validation verrouille la hiérarchie	Valider · Verrou structurel
12.6 L'annulation rouvre les enregistrements	Annuler
13.1 Opérations envoyées séparément	Synchronisation
13.2 États intermédiaires valides	Synchronisation
13.3 Déclencheurs de synchronisation	Synchronisation
13.4 Ordre des opérations	Synchronisation