Dans ce cas, un WMS sera certainement plus adapté qu’un ERP.
Pour le reste (appro) c’est clairement pertinent.
Bonjour,
Le sujet semble intéresser quelques utilisateurs 
pour information : quelqu’un a posté un autre cas d’usage sur l’issue github
Si d’autres utilisateurs pouvaient eux aussi donner leur cas d’emploi ici (pour ne pas encombrer github inutilement), histoire d’avoir suffisamment d’exemples et de ne pas passer à la trappe des cas d’usage répandus.
Au pire, allez mettre un petit « +1 » sur github pour montrer l’intérêt 
1 « J'aime »
Bonjour 
@Arre pour mon activité cela peut être utilise.
Nous achetons en toron etc des câbles ou autre qui sont des consommables. Mais pour du sav c’est vendu au mètre.
Bonjour à tous ceci serrait vraiment un plus tres stratégique pour notre ERP, pour ma part beaucoup de contribution ont déjà été faite et je crain de dire ce qui a déjà été dit, mais je voudrai savoir s’il serait possible d’utilisé la gestion des emballages aussi et si possible de definir un dictionnaire de format d’emballages.
1 Cas distribution brassicole
1.1 Livraison fournisseur en cassier de 12 bouteille, cassier de 24 bouteille, palette de 24 canette, palette de 6 bouteilles plastiques, en fu etc …
1.2 Livraison client soit en cassier, 1/2 cassier + 2 bouteilles +15 cannettes
serai t’il possible d’avoir une gestion assé précise de ce cas de figure?
1 « J'aime »
Bonjour à tous,
Mon activité industrielle donne les cas possibles suivants :
Produit A ( exemple : tube acier ):
Unité de gestion interne : mm
Unité d’achat : kg
Unité de vente : mm
Produit B ( exemple tube flexible )
Unité de gestion interne : mm
Unité d’achats : au rouleaux de 25, 50 ou 100 ft ( pieds mesure anglaise )
Unité de vente : mm
Produit C ( exemple : tube inox ):
Unité de gestion interne : mm
Unité d’achat : m
Unité de vente : mm
1 « J'aime »
Je rejoins ce qui a été dit plus haut, nous rencontrons beaucoup de cas d’usage où la conversion d’unités pose problème.
@Arre l’implémentation proposée semble en effet aller dans le bon sens, merci pour ce travail.
J’ai cru comprendre sur la page GitHub qu’une proposition est faites pour intégrer au dictionnaire des unités une colonne « ref » permettant de lier cette unité à un produit/service, de même qu’une colonne « coef » pour la conversion de cette unité dans l’unité de base.
Je m’interroge sur la pertinence d’avoir cette information dans le dictionnaire et donc accessible et configurable uniquement pas les administrateurs. Ne serait-il pas intéressant de proposer cette configuration sur la fiche produit ? De cette manière, un responsable des achats ou de production pourrait avoir la main sur la gestion des unités d’un produit sans pour autant devenir administrateur de Dolibarr et sans faire appel à celui-ci.
Le dictionnaire pourrait servir à configurer les unités exotiques et leurs liens avec les unités standards (donc y ajouter uniquement la colonne « standard_unit ») puis une interface sur les produits (pourquoi pas dans un onglet « Unité » sur la fiche produit) proposerait un tableau permettant de définir les coefficients de conversion d’un produit appliqués aux unités existantes dans le dictionnaire. Qu’en pensez-vous ?
Il me semble intéressant de conserver un dictionnaire pour la définition des liens uniquement mais pas forcément pour la configuration du quotidien. J’essaye d’imaginer un dictionnaire des unités avec des centaines de produits et des conversions différentes pour chacun et cela risque d’être un peu confus.
1 « J'aime »
Thibault,
Pour compléter mon analyse :
Si l’on créer une table de correspondance avec 3 champs
fk_product fk_unit coefficient
On peut relier chaque produit à plusieurs unités de mesures.
L’unité de gestion ( celle pour les stocks ) aura toujours un coefficient égal à 1
Pour les autres , le coefficient sera défini suivant les cas :
Produit A :
Unité de gestion interne : mm
Unité d’achat : kg coefficient = 0.0125 si chaque mm pèse 0.0125 kg
Unité de vente : mm coefficient = 1
Produit B ( exemple tube flexible )
Unité de gestion interne : mm
Unité d’achats : au rouleaux de 25, 50 ou 100 ft ( pieds mesure anglaise ) coefficient = 7500 , 15000 ou 30000 car 25 ft = 7500 mm …
Unité de vente : mm coefficient = 1
Produit C ( exemple : tube inox ):
Unité de gestion interne : mm
Unité d’achat : m coefficient = 1000
Unité de vente : cm coefficient = 10
Bonjour !
Je commence la rédaction d’un cahier des charges, vous pouvez continuer à voter dans le sondage ci dessus, à donner des exemple d’utilisation et à exprimer des besoins: je verrai si ça peut rentrer dans ce qui est « raisonnablement » prévu.
Je publierai le cahier des charges ici pour le soumettre à vos critiques.
4 « J'aime »
Bonjour tout le monde,
comme promis, voici un premier jet du cahier des charges.
Le périmètre fonctionnel est :
- unité d’achat, vente, stock, production, etc… sur les fiches articles (produit ET services)
- conversions entre ces unités (potentiellement différentes selon l’article)
- aide à la saisie des pièces commerciales (client et fournisseur) et internes (prod, inventaire,…)
- visualisation des informations un peu partout dans dolibarr (sur les PDF, les écrans de consultation, etc…)
- ajouter une gestion possible des articles qui soit en dehors des circuits de vente
Bonne lecture et n’hésitez pas à critiquer / à poser des questions / des ajouts / suppressions … !
Vous aimez ? dites-le !
Vous n’aimez pas ? dites-le aussi !
2 « J'aime »
Bonjour,
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.
1 « J'aime »
Bonjour @Maurice63200
Mince 
J’ai si mal expliqué les choses que ça ?
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 ?
2 « J'aime »
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!
Bonjour @zzillou ,
aucun problème :
si l’unité n’existe pas dans ce qui est livré en standard, tu pourras la créer :
- ou dans le dictionnaire si la conversion carat <-> g est constante quelque soit l’article
- ou article par article si la conversion est propre à chaque article
Tu pourras même créer le Mcarat (1 000 000 de carats) pour les plus gros cailloux 
1 « J'aime »
Bonjour à tou.te.s !
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)
Bonne lecture aux courageux !
2 « J'aime »
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.
1 « J'aime »
Bonjour @Maurice63200 ,
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é.
1 « J'aime »
Aimerai bien voir validé cette proposition pour un test en prod
