Gestion des transactions

Le cœur du produit est la transaction: c'est elle qui écrit l'histoire du stock. Cette page explique à quoi servent les types de transaction et comment choisir le bon flux.

FluxChaîne de transactionEmplacement réservé pour un visuel, un schéma ou une capture.

Types principaux

Type	Ce que ça veut dire
approvisioning	entrée fournisseur
inner_sale	transfert ou vente interne entre structures de la même organisation
local_sale	vente locale vers une branche ou un dépôt du même périmètre
outer_sale	vente externe vers l'extérieur de l'organisation
client_sale	vente directe à un client
inner_loan	prêt entre entités internes
inner_request	demande interne avant mouvement
crates_adjustment	ajustement manuel de conditionnements ou de retours
create_empty	création de retours dans le stock
create_empty_full	création de retours liés à du produit retourné
create_empty_lost	casse ou perte
unsuitable	produit impropre à la vente

Comment choisir le bon type

Demande-toi d'abord ce qui se passe réellement:

Situation réelle	Type à regarder
un fournisseur livre du stock	approvisioning
un produit est transféré ou vendu à une structure interne	inner_sale
un produit part vers un site local du même périmètre	local_sale
un produit sort vers l'extérieur de l'organisation	outer_sale
un client prend un produit	client_sale
du stock circule entre entités	inner_loan ou inner_request
des retours sont créés ou corrigés	create_empty* ou crates_adjustment
un produit n'est plus vendable	unsuitable

Flux recommandé

1. Identifier l'origine.
2. Choisir la destination.
3. Ajouter les lignes produit.
4. Vérifier les quantités et les statuts.
5. Confirmer l'écriture pour que le stock soit recalculé.

Ce que fait chaque étape

• identifier l'origine évite de mélanger deux sites ou deux clients;
• choisir la destination détermine où le stock va réellement;
• ajouter les lignes produit permet à l'application de calculer le stock;
• vérifier les quantités et les statuts évite les erreurs de saisie;
• confirmer l'écriture fige l'opération dans l'historique.

Scénario 1: réception d'une livraison fournisseur

Un magasin reçoit 4 cartons de 12 unités d'un fournisseur.

1. Type: approvisioning — le fournisseur livre du stock.
2. Origine: le fournisseur (acteur).
3. Destination: la branche du magasin.
4. Lignes: produit concerné, quantité = 4 cartons × 12 unités = 48.
5. Validation: le stock passe de 0 à 48 unités.

→ Ce type de transaction peut être saisi hors ligne si la réception a lieu sur le terrain.

Scénario 2: transfert entre deux branches

Un dépôt central envoie 10 unités vers une boutique.

1. Type: inner_sale — transfert interne entre structures de la même organisation.
2. Origine: la branche du dépôt.
3. Destination: la branche de la boutique.
4. Lignes: produit, quantité = 10.
5. Validation: le dépôt perd 10, la boutique gagne 10.

→ Le stock total de l'organisation reste inchangé. Seule la répartition entre branches change.

TransfertExemple: transfert entre branchesEmplacement réservé pour un visuel, un schéma ou une capture.

Scénario 3: vente à un client

Un agent vend 3 unités à un client.

1. Type: client_sale — vente directe.
2. Origine: la branche active.
3. Client: sélectionné dans la liste des acteurs.
4. Lignes: produit, quantité = 3.
5. Validation: le stock diminue de 3.

→ Si l'agent est en tournée sans réseau, il peut saisir la vente hors ligne. Elle sera synchronisée à la reconnexion.

Scénario 4: mise au rebut

2 unités sont endommagées et doivent être retirées du stock.

1. Type: unsuitable — produit impropre à la vente.
2. Origine: la branche où elles se trouvent.
3. Lignes: produit, quantité = 2, statut inactif.
4. Validation: le stock actif diminue de 2, un historique de perte est créé.

→ Ce type d'opération est tracé pour éviter les écarts de stock injustifiés.

Hors ligne

Seules certaines transactions peuvent être créées hors ligne:

• vente externe (outer_sale)
• vente client (client_sale)
• entrée fournisseur (approvisioning)

Elles sont ensuite synchronisées vers POST /api/transactions. Cela permet au terrain de continuer à travailler sans réseau stable, tout en conservant un envoi centralisé ensuite.

Point de vigilance

Les ajustements ne doivent pas être utilisés comme un raccourci pour masquer une erreur métier. Ils doivent documenter une réalité opérationnelle. Si l'ajustement sert à corriger une erreur de saisie, il faut revoir le workflow d'origine.

À lire ensuite

• Modèle d'inventaire — comprendre la structure des produits
• Cycle de vie des données — comment une transaction évolue dans le temps
• Mode hors ligne — fonctionnalités disponibles sans réseau