Avez vous besoin d’unité de gestion différentes pour un même produit, dans différents workflow ?
Exemple :
Pour ma référence AAA, j’achète en « palette » (de 125m2)
Je gère mes stocks en « m2 »
Je vends en « paquet » (de 1.25 m2)
Je consomme pour une fabrication au « kg » (avec 1 kg = 0.8 m2)
etc…
(ces facteurs d’unités peuvent être différents d’une référence à l’autre)
vital pour tout ou partie de mon activité
oui, ça peut être utile
non
0votant
ne vous emballez pas : c’est juste un sondage pour voir si ça suscite l’intérêt ^^
c’est plus qu’une unité de conditionnement (mais ça les englobes), exemple : stocker en m2 (pour avoir une visibilité directe sur le métrage installable) et de vendre au colis,
c’est aussi une conversion d’unité physique.
Certains métiers ont besoin d’acheter au kg, mais de ventre au mètre linéaire par exemple la métallurgie, ou de stocker en kg et de consommer au litre, par exemple un applicateur de vernis industriels.
Et forcément… un kg de A ne donne pas le même nombre de mètres linéaires que B…
C peut avoir une masse volumique différente de D…
De plus aujourd’hui, les unités ont une relation en puissance de 10 stockées: ça empêche les autres conversions (système d’unité impérial ou conversions chimiques mole->m3, etc…)
et aujourd’hui les unité sont scindées en « catégories » : tu ne peux pas faire correspondre une surface à un poids.
Tout ça oblige à passer par des conditionnements ou pire, des OF, pour convertir; alors qu’une bête table liée à l’article fait le job et permet les conversions ans tous les sens.
Dans cette table les conversions sont ou attachées à rien (réalité physique) : un dm vaudra toujours 0,1 m ou pas : un colis de produit A vaut 1.05 m2, un colis de B vaut 1.80 m2, un container de C vaut 12436 m2, 1 kg de E donne 0.8 ml, 1 kg de F donne 0.95 ml, etc…
Bonjour, pas utile pour moi, mais par contre ca permettrait de calculer le cout du stockage depuis l’ERP directement: je loue un entrepot et paye a la palette, ce qui represente un poste de depense important que j’apprecierais de suivre dans Dolibarr: il suffirait de savoir combien il y a de produits XX par palette et le cout par palette/jour pour avoir les frais de stockage exploitables.
En confection,
1_ On achète le tissu au Kg (parfois au mètres) (Stock Matières 1ère)
2_ On passe du kg au mètres au Service chargé de la coupe (Produits en cours)
3_ On passe d’unités sortant de la Coupe vers la Fabrication (produits en cours)
et puis on obtient des vêtements (unité). (Stock produits finis)
Pour le fil, c’est complexe quant au calcul des coûts.
Ce que je vois chez les autres ERP (open-source et propriétaire) c’est
1 - unité de stockage par defaut
2 - unité par défaut à l’achat (optionnellement par fournisseur) et surtout un prix par unité possible et facteur de conversion entre les deux.
3 - unité de vente par défaut et facteur de conversion entre les deux
Cela veux dire que à la saisie des devis/commande/facture, client et fournisseur on peux choisir l’unité, mais au mvt de stock on reviens toujours à l’unité de stock par défaut.
Pour le facteur de conversion entre les unités, il y a plusieurs écoles. Une conversion globale (par exemple dans « dictionnaire »). D’autre ERP vont jusqu’à mettre sur l’article les taux de conversion; comme si sur un article 1kg=1000g alors que sur un autre se serais différent…
@FHenry oui je fais le même constat, avec la même chose sur les workflow d’inventaire, de fabrication et des états « métiers » (quelqu’un qui fais des chiffrage veut voir ses stocks en m2 alors que son collègue qui gère l’entrepot veut les voir en palettes par exemple)
J’ai essayé de donner des exemples et d’illustrer sur github.
Bonjour,
très intéressant comme discussion.
Il y a une unité qu’il ne faut pas oublié : le carton
Exemple
Produit A : unité de vente : unité ou carton ou palette
fournisseur E : 1 palette = 10 cartons
fournisseur R : 1 palette = 12 cartons
Maurice pousse le bouchon un peu plus loin
fournisseur E : 1 carton = 20 unités
fournisseur R : 1 carton = 18 unités
Cet exemple qui est loin d’être rare montre qu’il faut plutôt paramétrer au niveau métier et article
Dans ce cas
les appros / achats ne sont intéressés que par le nombre de cartons pour un fournisseur donnés
le commercial par les unités de ventes
la logistique / dépôt par la palette pour le stockage, le carton pour alimenter le picking qui lui veut connaitre l’unité de vente (par exemple l’unité de vente du produit A aurait pu être par 2)
Avec tout ca le challenge est de pouvoir consolider les stocks …
@WebAuxilium justement, l’idée est de NE PAS imposer les unités et leurs coefficients (sauf à livrer « en standard » les unités physique : l = 0.01 Hl = 10 dl = 1000 ml ou kg = 0.001 tonne = 1000 mg, etc…)
Dans ton cas, il faudrait pour cet article paramétrer pour ce produit « ABC », par exemple :
1 CAR20 = 20 UN
1 CAR18 = 18 UN
1 PAL10 = 200 UN
1 PAL12 = 216 UN
(tout est calculé en fonction de l’unité standard, non modifiable une fois l’article créé)
la fiche de ABC contiendrait :
unité standard = UN (non modifiable)
unité de stock = PAL10 (ou PAL20… c’est juste une unité qui sera proposée par défaut) (ou PALA, PALB, …)
unité d’achat = CAR20 (ou CAR12…c’est juste une unité qui sera proposée par défaut) (ou CAR A, CARB…)
unité de vente = UN (ou CARX, ou PALX…c’est juste une unité qui sera proposée par défaut)
L’article est géré:
en UN par dolibarr (standard)
Les ventes peuvent se faire dans n’importe quelle unité, par défaut sera proposée UN, à la validation de la ligne : on vérifie que le stock est suffisant dans l’unité choisi en comparant aux mouvements de stock (exemple, impossible de vendre 2 PAL10, s’il ne reste que des PAL12)
Les achats peuvent se faire dans n’importe quelle unité, par défaut sera proposée PAL10 ou l’unité renseignée dans le prix d’achat du fournisseur, ou modifié à la main
etc… pour les mouvements internes, pour les consommations de fabrication, les production, etc…
et ça peut bien sût être différent pour un autre produit…
Il faut bien sûr que la quantité en unité standard soit stockées dans chaque mouvements, lignes, etc… et jamais recalculée si le colisage change (exemple : avant il y avait 10 UN dans 1 CARTON… si le fournisseur change et y met 12 UN … il ne faut pas que le passé soit recalculé… d’où l’utilité de mettre des indice, des nombre, des lettres dans les codes des unités parfois)
@Arre
Ok je comprend mieux et effectivement cette proposition va dans le bon sens des améliorations de Dolibarr.
Dans notre cas ca pourrait résoudre une partie de nos problèmes , sans toutefois résoudre notre principale problème (mais sur ce dernier point, je n’ai pas encore trouver un seul erp qui sache le gérer en natif )
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
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?
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
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.
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
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.
)
