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…
Bonjour,
Déjà, bravo pour ce travail préliminaire et ce cahier des charges !
Du côté d’altairis, nous n’avons pour l’instant pas eu de demandes sur ce sujet mais ça peut changer…
Ce que je peux suggérer serait donc plutôt au niveau de l’intégration dans Dolibarr.
Je pense (très fort) qu’il faudrait que ce développement soit fait sous forme de module (core ou externe) et soit entièrement débrayable pour ne pas « polluer » les écrans avec des champs supplémentaires qui ne seront pas utiles à tout le monde.
Des champs qui ne s’affichent que si le module est activé, voire des onglets spécifiques.
Il faudrait également à mon sens que le code soit bien à part et ne rajoute pas encore des lignes et des lignes aux scripts existants; du travail a déjà été effectué ces derniers temps avec des scripts core/actions_mafonction.inc.php par exemple et il serait vraiment utile d’aller dans cette direction voire de généraliser cette approche, y compris pour la définition des écrans.
Merci à tous celles et ceux qui m’ont fait un retour sur le forum, par email ou en visio!
Il ressort des remarques sur:
La clarté des objectifs/conséquences projet:
Le projet est difficilement compréhensible par quelqu’un qui arrive maintenant, sans avoir suivi depuis le début → je vais donc faire une page de présentation/mise en contexte.
Comme pour le point précédent : un utilisateur lambda ne comprend pas le CDC → je vais faire un effort de présentation/rédaction plus « grand public »
j’ai souvent eu à expliquer que le projet ne visait pas à modifier ou ajouter une gestion des poids/dimensions/colisage des articles pour leur réception ou leur expédition → je vais le préciser plus clairement en première page.
La technique:
Une vigilance particulière doit être portée sur l’intégration : il ne faut pas trop complexifier le code existant pour des raisons de maintenance future. → Il faut donc se (re)poser la question sur le mode d’intégration : dans le core comme envisagé ? ou module du core ? ou module externe ? (je ne maitrise pas l’impact que cela peut avoir sur le cout de développement: des avis sont les bienvenus)
Certain(e)s ont compris que le projet était de changer toutes les tables avec pleins de conversions et de champs quantité/libellés dans tous les sens : pas du tout. → Je vais éclaircir ça dans la prochaine version du CDC.
Des inquiétudes sur le fait que les modifications envisagées aient des effets de bord sur la compatibilité des modules externes → je ne pense pas, mais ça sera intégré dans le cdc
La question des risques d’arrondis a été soulevée plusieurs fois → je vais préciser le « garde fou » prévu dans le cdc plus clairement.
Le fonctionnel:
Un point « juridique » ou « comptable » a été soulevé : la possibilité de commercialiser un produit sous différentes unités, avec des conversions.(!!!) → j’ai contacté une experte comptable, un commissaire aux compte et un contrôleur de gestion : tous m’ont confirmé que c’était de la gestion pure et qu’il n’y avait aucune contrainte.
Des arguments d’utilisation des OF actuels apparaissent pour réaliser les conversions : c’est possible, mais utile uniquement s’il y a transfert de stock, modification de la valorisation (valeur ajoutée ou dépréciation) ou opération de transformation, sinon c’est le marteau pilon pour écraser une mouche.
Des arguments d’utilisation des KIT actuels apparaissent pour réaliser les conversions : c’est possible mais, c’est une utilisation détournée de l’idée de base des kits à mon sens: cela oblige a utiliser N produits/services (un par conversion), ne permet pas de visualiser les stocks physique existant dans la conversion souhaitée et n’est pas ergonomique d’un point de vue saisie.
L’ergonomie:
J’ai eu quelques retours sur l’ergonomie, notamment sur la saisie des lignes achat/vente → tout ne sera pas possible, mais il y a 2 ou 3 bonnes remarques à intégrer (ça reste un cahier des charges fonctionnel, pas le maquettage d’un livrable!)
un retour sur le risque de complexifier les saisies : je pense que c’est un manque de clarté et/ou de lecture du cdc. → à vérifier
voili voilou
si vous avez des commentaires sur un ou plusieurs points ci dessus n’hésitez pas!
La V3 du cdc devrait sortir fin de semaine prochaine.
J’ai si mal expliqué les choses que ça ?
