Bug Create contract

This commit is contained in:
2026-05-14 17:11:54 +02:00
parent 18c0329a94
commit 160ec1544b
6 changed files with 101 additions and 77 deletions

View File

@@ -161,6 +161,11 @@ quantity_theorical
- create one `virtual` lot.
- The virtual lot receives a first `lot.qt.hist` entry.
- `Lot.validate` creates the open `lot.qt` through `createVirtualPart`.
- If the line is `created_by_code`:
- it comes from a business workflow (`Create contracts`, matching, etc.);
- `Lot.validate` does not create an automatic open `lot.qt`;
- the workflow attaches or splits its source `lot.qt`;
- the blocking check applies only after the workflow is stable.
### Updating `quantity_theorical`
@@ -266,6 +271,11 @@ free_quantity = target_quantity - sum(already matched or shipped lot.qt)
- Central check:
- `lot.lot.assert_lines_quantity_consistency()`
- Trigger rule:
- block inconsistent final states;
- do not block internal transient workflow states;
- use `Lot.skip_quantity_consistency()` only around a sequence that restores the invariants afterwards;
- call an explicit final check after the sequence.
- Non-zero orphan `lot.qt` block:
- `lot.qt.validate`
- Called after:
@@ -273,7 +283,11 @@ free_quantity = target_quantity - sum(already matched or shipped lot.qt)
- physical lot creation / deletion;
- matching / unmatching;
- shipping / unshipping;
- matched `Create contracts`;
- weighing.
- The `created_by_code` case is intentionally excluded from the immediate `Lot.validate` check:
- the virtual lot is saved before the matched `lot.qt` is attached;
- the invariant is checked by the final workflow guard.
### SQL Diagnostic

View File

@@ -160,6 +160,11 @@ quantity_theorical
- création d'un lot `virtual`.
- Le lot virtuel reçoit une première entrée `lot.qt.hist`.
- `Lot.validate` crée le `lot.qt` ouvert via `createVirtualPart`.
- Si la ligne est `created_by_code` :
- elle provient d'un workflow métier (`Create contracts`, matching, etc.) ;
- `Lot.validate` ne crée pas de `lot.qt` ouvert automatique ;
- le workflow rattache ou subdivise son `lot.qt` source ;
- le check bloquant s'applique seulement après stabilisation du workflow.
### Modification de `quantity_theorical`
@@ -264,6 +269,11 @@ free_quantity = target_quantity - somme(lot.qt déjà matchés ou shippés)
- Check central :
- `lot.lot.assert_lines_quantity_consistency()`
- Règle de déclenchement :
- bloquer les états finaux incohérents ;
- ne pas bloquer les états transitoires internes d'un workflow ;
- utiliser `Lot.skip_quantity_consistency()` uniquement autour d'une séquence qui rétablit ensuite les invariants ;
- appeler un check final explicite après la séquence.
- Blocage `lot.qt` orphelin non zéro :
- `lot.qt.validate`
- Appels après :
@@ -271,7 +281,11 @@ free_quantity = target_quantity - somme(lot.qt déjà matchés ou shippés)
- création / suppression de lots physiques ;
- matching / unmatching ;
- shipping / unshipping ;
- `Create contracts` en mode matched ;
- weighing.
- Le cas `created_by_code` est volontairement exclu du check immédiat `Lot.validate` :
- le lot virtuel est sauvegardé avant que le `lot.qt` matched soit rattaché ;
- l'invariant est contrôlé par le check final du workflow.
### Diagnostic SQL