SONDAGE: unités de stock/vente/achat/

Les intégrateurs qui passent régulièrement sur le forum : pouvez vous donner votre avis svp ?

@atm-maxime pour ATM
@aspangaro-Easya pour OPEN-DSI
@altatof pour ALTAIRIS
@FHenry pour SCOPEN
@Philazerty pour A3SYS
@defrance pour PATAS-MONKEY

N’hésitez pas en nommer d’autres ou à participer si je vous ai oublié ^^

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 ! :clap:

@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.

@altatof il suffit de lire le cdc v2: il prend tout en compte (pour l’instant)

1 « J'aime »

@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.

Bravo !

1 « J'aime »

Bonjour,

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.

2 « J'aime »

Bonosir @Arre merci pour ce travail
Pour avoir une idée plus clair, pour que les unités de conversions soit exploitable faudra transferé le stock dans un magasin aproprié pour les OF?

Bonjour
ça va être intégré dans quelle version de Dolibarr tous ça?
Merci

@TADIT

je ne comprends pas la question: le projet ne touche pas aux OF.

Rien ne change par rapport à aujourd’hui sur les OF, sauf qu’il est envisagé de pourvoir saisir les quantité dans une conversion, en plus de l’unité actuelle.
Exemple : tu gères un produit, du ciment, tu le gère en stock au sac, le vend en sac, mais la production préfère compter en kg, meme si c’est conditionné en sac.
Et bien ils pourraient déclarer les production au kg (exemple : je fabrique 250 kg de ce produit, ça rentre 25 sacs en stock)
ou au litre, ou en ce que tu veux…

Les conversions sont une possibilités « en plus » du champ d’aujourd’hui: c’est toujours la quantité d’aujourd’hui qui compte.

@BMC aucune idée :slight_smile:
A ce stade, je ne sais meme pas si ça verra le jour : c’est un PROJET ! (tu as lu la première page du cahier des charges ?)

une petite infographie expliquant le projet, issue du futur CDC V3 :slight_smile:

Cliquez sur les images pour agrandir.

1 « J'aime »

comme indiqué lors de notre discussion, pourquoi ne pas juste ajouter des onglets de conversion à titre d’information.
un au niveau du produit où l’on paramètre les conversions propre au produit
un autre au niveau des pièces (commandes, facture, …) affichant les quantité convertis (et pourquoi pas alors la possibilité de changer la quantité de manière inverse).
Ce genre de chose, je suis capable de te le développer en une journée en me basant sur mon module customProduct pour l’ergonomie

1 « J'aime »

Bonjour Charlène :slight_smile:

Merci encore pour nos échanges : j’ai modifié des choses dans la V3 du CDC grâce à toi. (comme ça a été le cas avec d’autres)

Les onglets, c’est le cas: (tu as lu le cdc v2 ? :wink: )

  • un onglet de la fiche article permet de saisir les conversions spécifiques à chaque article

  • le dictionnaire lui, est global à tous les articles (pour ne pas avoir à dire que 1000 m = 1 km sur chaque articles). En fait, il ne sert qu’a renseigner les unités internationales et leur conversions + création des unités « à vide » pour les utiliser ailleurs… mais après tout, pourquoi ne pas simplement abandonner le dictionnaire et de n’avoir qu’un onglet dans chaque article ?

  • j’avais envisagé l’onglet sur les saisie de pièces commerciales, mais je pense qu’un « popup » java, dynamique avec renvoie des valeurs sélectionnées/saisies dans la page actuelle est plus user-friendly (en tout cas, ça va dans le sens de l’ergonomie et les clics dont on a discuté ensemble). Un onglet obligerait à saisir toutes les lignes, puis à revenir sur chacune, ou à saisir une ligne, changer d’onglet, revenir saisir la 2eme, changer d’onglet, etc…

Pour rappel: ce ne sont pas que « mes » idées qui sont dans ce CDC, mais la compilation de tout ce que j’ai pu lire à ce sujet sur ce forum, sur github et des échanges que j’ai eu (visio, mail, tel…)

Le cahiers des charges V3 sera bien plus simple à lire que le V2 pour ces points, il sera dispo milieu de semaine prochaine.

L’objectif est de trouver un preferd partner qui sache développer ça, et de lui passer le bébé : charge à lui d’organiser le financement participatif (je peux donner un coup de main) et de développer ce qui sera financé, pour intégration dans le core (sous forme de module, ou par modif des modules existants, la discussion a été lancée avec les lead dev, notamment @eldy, avec une option « d’activation » pour ne pas perturber ceux qui n’en ont pas besoin).

1 « J'aime »

Merci cela répond à mon besoin attendons voir cela en beta pour tester

Bonjour,

je clôture ce post, qui à l’origine ne devait être qu’un sondage.

Merci à toutes et tous d’y avoir participé.

La suite du projet se déroulera ici :