merci pour les quelques retours que j’ai eu un privé (n’hésitez pas à commenter en publique : ça sera profitable à tout le monde ! )
Une version 2 des spec est en préparation.
Il est également temps de sonder les dev et la communauté internationale sur le sujet.
Voici donc le début des échanges sur github : (ceux qui maîtrisent l’anglais peuvent bien sûr interagir sur github également)
Bonsoir
J’ai donc passer un moment à lire les échanges en anglais sur github.
Et j’ai l’impression que tout cela est assez éloignéde la problématique des unités de ventes ,d’achats et de stocks.
En résumé pour moi le pb est le suivant
Pour un produit donné il peut coexister une unité d’achat, une unité de stockage et une unité de vente.
Il faut définir les coefficients qui permettent la conversion entre chacune de ces unités.
Le coefficient qui lie l’unité d’achat avec l’unité de stockage permet lors de la réception de x unités d’achats, d’incrémenter les stocks de y unités de stock. Par exemple je commande 12 kg d’acier en diamètre 15 mm parce que mon fournisseur le vend au kilo et je reçois 18m ou18000 mm de rond de diamètre 15, que je stocke et que je vais consommer par morceaux. Je commande donc 12 kg à 5 euros soit 60 euros et à la réception j’incrémente mon stock de 18000 mm à 0,00333 euros /mm .
Néanmoins je vais rester attentif sur les avancées possibles.
C’est exactement ce que permet (entre autre choses) la proposition d’évolution.
Je reformule ta problématique avec l’idée contenue dans le projet :
Ton produit a une unité standard (c’est déjà l’unité actuelle accessible par "PRODUCT_USE_UNITS) qui fait référence à la quantité actuelle de dolibarr, qu’on retrouve partout. (disons que pour ce coup, ça sera KG)
Cette unité possède des conversions (le dictionnaire actuel) qui seront exprimées en décimal (pas en scale comme aujourd’hui pour être plus souple) vers d’autres unités du système international et communes à TOUS tes articles (kg<->g, kg<->tonne, kg<->once, etc…)
Ton produit a aussi son « dictionnaire » à lui (un onglet de la fiche produit), où tu peux définir la conversion de n’importe quelle unité, en n’importe quelle unité, pour ton exemple : m = 0.6667 kg
Ton produit a aussi une unité d’achat, une unité de vente, une unité d’inventaire, une unité de fabrication… sur la fiche article : c’est l’unité qui sera proposée par défaut dans les workflow concernés (mais bien sûr modifiable par n’importe quelle unité du dictionnaire possédant une conversion avec l’unité standard de l’article ou par n’importe quelle unité du « dictionnaire » propre à cet article.
Tu veux vendre les barres à l’unité (de 2m) ? pas de problème, tu définis UN = 1.2222223 kg sur la fiche article
Tu veux vendre en botte de 10 ? pas de problème, tu définis BOT10 = 12.222223 kg sur la fiche article
Tu veux vendre au litre ? pas de problème tu défini L = 4.53 kg sur la fiche article
etc…
Une fois cela paramétré (ou importé) une bonne fois : (TOUT est modifiable à tout moment, sauf l’unité standard)
tu peux indifféremment acheter et vendre en KG, en M (comme tu l’envisages) ou en L, ou en botte de 10… ce que tu veux !
Tu peux aussi saisir tes prix de vente dans n’importe la quelle des unités:
prix au KG
prix au M
prix à l’unité
prix à la botte de 10
prix au camion…
pareil pour les prix d’achat, dans les même unité que les prix de vente, ou dans d’autres unités :
prix au KG
prix à la tonne
prix au mg…
(ça restera bien sûr compatible avec les systèmes de prix actuels avec seuil, multi clients, etc…)
Pour info : derrière, dolibarr fonctionne comme aujourd’hui avec une seule unité (rebaptisée « unité standard ») et sa quantité associée:
toutes les saisies sont toujours ramenée à cette unité standard pour le fonctionnement de dolibarr (tout en mémorisant la saisie dans l’autre unité, histoire de ne pas se taper des problème d’arrondi)
partout dans dolibarr : tu peux visualiser les quantité en unité standard dans l’unité de ton choix
les unités d’achat, de vente, de… ne sont pas obligatoirement l’unité standard : dolibarr peut gèrer en « stroumpf » et toi, acheter en kg, vendre en m, voir tes stocks en palettes, etc…
Est ce que c’est plus clair ainsi ?
Est ce que ça répond à tes interrogations ?
Bonjour @Arre
Pour ma part, il serait intéressant de pouvoir utiliser comme unité de poids le carat (poids pour les pierres précieuses) qui est équivalant à 0.2 g.
Donc très intéressé par le sujet
Merci infiniment pour l’amélioration continue de ce super ERP!
Le cahier des charges fonctionnel est sorti en V2 en fonction des retours que j’ai eu et de quelques discussions avec des développeurs.
Principales modifs par rapport à la V1 : en bref, plus simple et centré sur l’objectif initial : gérer des conversions dans le dictionnaire d’une manière plus souple qu’aujourd’hui et faciliter les saisies/lectures d’informations sur les flux ventes/achat/fabrication/inventaire/fabrication…
l’unité « standard » (le label de la quantité actuellement géré partout dans dolibarr) n’a plus d’impact sur le fonctionnement de dolibarr (ça devient totalement optionnel pour une parfaite rétrocompatibilité)
précisions sur les conversions du dictionnaire/article par article
ajout du détail de l’impact des unités sur les tarifs d’achat et de vente
simplification de la fiche de conversion article par article
diminution de l’impact sur la fiche article (plus aucune contrainte en fait )
amélioration de l’ergonomie de saisie dans les ventes/achats
aide à la sélection de lots / numéro de série
abandon de la différentiation des stocks en fonction de leur unité d’entrée (on laisse ça pour un projet/module futur orienté WMS-réception-expéditions avancées)
abandon de la gestion des Lxlxh surface et volume par unité (on laisse ça pour un projet/module futur orienté WMS-réception-expéditions avancées)
Bonsoir Arre
Ton cdc est clair et réponds bien à notre problématique. Et je n’ai jamais dit le contraire
Par contre ce que je soulevais dans mon dernier message c’est que les discussions en anglais sur le github en étaient, elles, malheureusement trop éloignées et réductrices.
Et par conséquence , je doute qu’en final le rendu soit efficient.
Pour info, j ai créé un attribut supplémentaire de produit onglet Prix fournisseur qui me permet une conversion entre l’unité standard et l’unité d’achat. Reste beaucoup de dev mais pour mon cas cela semble une bonne approche.
Les discussions dans github se font (et vont se faire) autour de:
la pertinence d’intégrer les fonctionnalités proposées
la vérification que ces fonctionnalités ne rentrent en collision ni avec l’existant, ni avec le prévu
l’estimation de l’éventuelle « complexification » des scripts et de leur maintenance future
la forme, l’ergonomie (d’utilisation et d’intégration)
l’adéquation entre la volonté des lead dev (essentiellement @eldy) pour le projet dolibarr et ces propositions
Donc oui, ça peut rentrer très loin dans des détails, se focaliser sur des points précis ou même faire évoluer considérablement le cadre de ce qui a été pensé au départ dans le cdc.
Et pour l’instant, ça n’apporte que du plus (plus simple, moins contraignant)
C’est la vie normale d’un avant projet
Pour ces raisons : plus d’utilisateurs confirmeront leur intérêt pour l’idée, plus ils exprimeront d’avis, de propositions ou même d’opposition, plus vite ça avancera !
@atm-thibault milles excuses, j’avais zappé ton post
C’est ce qui est prévu :
Dans le dictionnaire, il y a toutes les unités (pour qu’elle soient crées et accessibles ailleurs) mais beaucoup seront sans conversion (car ces conversions sont propres à chaque articles)
Seules les coef des unités internationales seront présentes dans le dictionnaire m ↔ km, L ↔ ml etc…
Pour les articles, ça se passe dans un onglet de leur fiche « unité » ou « conversion »… à définir
Là tu peux créer UN = 3 kg, PAL = 25 UN, etc…
ou même km = 937 m ça surcharge le dictionnaire (je sais, ça parait con… mais pourquoi pas ?)
Ce qui est prévu est à mi-chemin, car il serait chronophage de définir que 1 km = 1000 m sur chaque article, alors qu’on peut le faire une fois pour toute dans le dictionnaire (et surchargé si besoin sur les articles)
Les unités « exotiques » ou n’appartenant pas au système internationale sont seulement déclarées dans le dictionnaire, sans coef (les coef le seront sur chaque article) ni lien avec une autre unité.
@Arre merci pour ce super travail et ta réponse ! C’est un gros morceau qui répond à un besoin plutôt commun des utilisateurs que l’on peut rencontrer sur Dolibarr, le CDC me semble complet et cohérent, bravo, c’était pas gagné
Je partage l’avis de @atm-thibault , c’est un travail de qualité qui réponds à un besoin qui est adresser dans les autre ERP du marché (c’est par ce que il le fond qu’ils ont raisons, mais ça répond à besoin).
Apprentis tout particulièrement la démarche participative de l’approche pour pousser quelque chose dans le coeur de Dolibarr. Bravo !
@Arre j’avais répondu au sondage; j’essaierai de prendre du temps ce week-end pour lire en détail le fil de discussion qui a suivi. Je suis un peu débordé en cette fin de semaine…
pour avoir géré des trucs dans ce domaines (pour le calcul de poids dans les transports)
je dirais qu’il y a déjà des unités de conversions par famille d’unité et je ne vois pas trop le besoin d’aller plus loin.
si j’ai besoin d’un produit dans une autre unité, ben j’utilise les produits virtuels ou une fabrication pour ajuster le ou les produits à la bonne unité
Ce qui m’inquiète c’est que gérer les unités à la saisie des pièces va encore complexifier cette saisie alors qu’elle devrait justement être simplifié (ou alors prévoir deux modes de saisie, de base et expert pour les cas tordus)
bonjour,
le besoin de gérer des conversions entre unités n’est pas virtuel.
Personnellement j’ai le cas plusieurs fois par mois .
J’achète de la matière première au kilo mais que je stocke dans mes entrepôts au millimètre et que je consomme dans mes OF également au millimètre.
Et malheureusement le coefficient de conversion entre les kilo achetés et les millimètres stockés n’est pas unique : il dépend de chaque article.
Je ne vois pas comment je pourrais utiliser les articles virtuels.
Le cdc de Arre est très précis et détaille toutes les possibilités.
@Maurice63200
prenons le cas d’un produit A1 définis par 3Kg et un produit A2 définit par 1millimère dans ton cas
si je fait une composition de A2 où j’indique qu’il est composé de 0.003 A1, la décompositon de A1 permet d’obtenir la bonne conversion (on peu meme avec factory indiquer la perte des décomposé si on obtient pas précisément les quantité de A2
a mon sens c’est une meilleure manière de faire car la décomposition n’est pas forcément parfaite…
J’ai si mal expliqué les choses que ça ?
