Bonjour à tous, j'ai donc rédigé un petit cahier des charges synthétique pour commencer. Bien entendu, tout ceci est le fruit de ma compréhension sûrement partielle de Dolibarr et du métier d'achat/vente. En gros, AS IS comme d'habitude. Et si j'ai omis des fonctionnalités existante, et bien je serai ravi de me les faire enseigner.
Je vais dans un premier temps (1) décrire les besoins afférents à l'utilisation des numéros de série sur des premiers et certains aspects de la gestion de stock.
Ensuite, lister (2) les actions sur des produits sérialisés (par opposition à des produits non sérialisés, comme, disons, des paquets de recharge d'agrafes)
Enfin, proposer (3) un CC semi-technique en listant par exemple les liens avec l'actuelle version de Dolibarr (2.2 ici).
(1)
Il est important de pouvoir tracer le transfert de propriétés d'un produit sérialisé, notamment dans le cas de contrats de service dont les éléments caractéristiques (date de prise d'effet d'un contrat de garantie par exemple) sont attachés au numéro de série (serial pour la suite). Du constructeur à l'utilisateur final, les intermédiaires (grossiste, revendeur) peuvent justifier de la date de commercialisation dudit objet.
Il est important aussi de savoir (dans une des 2 méthodes de valorisation de stock) quelle pièce a été achetée à quel prix. Prenons par exemple des cartes réseau. Sur une année complète, le même lot de 25 cartes sera acheté à un prix décroissant au long de l'année. Une carte du lot du mois de mars sera donc valorisée plus chère qu'une carte appartenant au lot de novembre. La valeur de mon stock est alors (selon ce que l'on souhaite)
- a] (Y pièces) x (Prix d'achat unitaire)
ou
- b] (Y pièces) x (Prix de vente unitaire)
Attention, il ne s'agit pas de la valorisation comptable du stock mais du point de vue de gestionnaire (a : j'assurer mmmmm euros de matériel, b: je dois vendre nnnnnn euros de matériel). Qui finit immanquablement par rencontrer celui du comptable. Et l'orientation 'pré'-comptable de Dolibarr me permet de croire que la différence est sensible.
Voir à ce sujet l'un des premiers docs retournés par Google sur la recherche 'CMUP' (l'une des méthodes de valorisation justement) :
www.ac-versailles.fr/cerpeg/ressdiscipl/compta/stocks.pdf
(2) (en rouge, les fonctionnalités)
Dolibarr permet très justement de passer commande à un fournisseur (de cartes réseau, mettons, NIC). Avec des prix d'achats par quantité autant que j'ai vu.
Normalement, je ne connais mes serials qu'au moment de la livraison (partielle ou totale).
C'est donc à la livraison que je peux, si ce type de produit exige une sérialisation, saisir les serials des éléments reçus.
De même, les produits à sérialisations reçus à l'occasion de la commande CFXXX_MMMMMM doivent pouvoir lui être rattachés. Si je cherche à retracer la 'vie' d'un produit dans la société, je dois retrouver sa commande
Ainsi, lorsque je reçois 3 x NIC-mod1 (3 exemplaires de la carte NIC modèle 1), je peux décider de les sérialiser (on a donc nettement affaire à une option du produit : ce produit est-il sérialisé ou non ?). Dans le cas de produits munis de serials, le BL du fournisseur précise normalement lesdits serials.
C'est donc à la définition du produit que je détermine si j'ai affaire à un produit exigeant la sérialisation, ou non
Or en toute logique je place mes produits reçus dans un stock, en attente de vente.
Les mouvements de stocks (entrepot-entrepot) doivent donc permettre de spécifier quels produits sont mouvementés (m serials parmi un stock de n à Entrepot1)
Une fois ces produits en stock, je dois les vendre. Je passe d'emblée sur le cas du client interne. Mais lorsque je revends à un tiers client, je dois pouvoir délivrer un BL spécifiant les serials livrés.
Doivent donc être attachés à ma facture les éléments de sérialisation d'un produit exigeant la séria. Cela me permettra de le reprendre dans le BL
La question se pose de sélectionner les produits qui seront acheminés au client
au moment de la commande. En effet, on préfèrera livrer en premier les éléments les plus chers du stock (dans le cas d'un suivi précis des achats/serias) afin de se prémunir contre une nouvelle perte de valeur.
(3)
J'ai tenté de modéliser un petit 'module' dans une application de BDD dont je tairai le nom. J'y suis simplement un peu plus agile.
Je me suis retrouvé à créer une simple table contenant un
rowid par convention et un champs texte tout simple :
- serial : le numéro de série du produit
Chaque enregistrement contient aussi une référence (fk_xxxxx) aux tables suivantes :
- commande_fourn : pour savoir d'où est issu ce produit
- facture_fourn : pour savoir combien et à qui il a été acheté
- entrepot : pour savoir où il se trouve
- commande : pour savoir à quelle commande il a été attaché
- facture : pour savoir combien et à qui il a été vendu
- product : pour savoir de quel type de produit on parle
Enfin, les informations additionnelles suivantes
- status : détruit, abîmé, prêté, vendu, stock, abandonné, etc...
- commentaire : typiquement, raison d'un changement d'état suite à inventaire
La table dispose d'un index absolument nécessaire outre le PRIMARY de rowid :
- UNIQUE (product, serial)
Voilà, un peu de débroussaillage. Pour le moment, je peaufine mon 'module externe'
Bonne fin de journée à tous.
