Gestion de Nomenclatures en Cascade

Utiliser mon Dolibarr Modules PM
,
1

Bonjour à vous tous,
J’utilise Dolibarr pour la gestion de ma micro-brasserie et j’essaie de mettre en place une gestion de production qui me permettra de coller à mes process de production :
Phase 1) Brassage de la bière et stockage en fermenteur pendant 1 mois. Une nomenclature de brassage me permet le déstockage des matières premières et le calcul des couts de revient (ça marche très bien). J’ai créé un produit spécifique (bière au litre) qui est stocké dans un entrepôt tampon correspondant à mon fermenteur. Jusque là, pas de problème, nous sommes dans un cas classique.

Phase 2 Mise en bouteille : Pour la mise en bouteilles, j’ai crée des nomenclatures pour chaque type de conditionnement (bout 33cl, bout 75cl, fût 5L, etc). Chaque nomenclature prélève, dans le stock correspondant au fermenteur, la quantité de produit nécessaire et ajoute les produits supplémentaires nécessaires au conditionnement (bouteille, etiquette, capsule, etc)

Au niveau des stocks, tout fonctionne parfaitement.
Par contre le cout de revient unitaire calculé dans la nomenclature de la phase 1 n’est pas repris dans la nomenclature de la phase 2, au moment de la mise en bouteille. Pour contourner le problème, je suis obligé de saisir manuellement le cout au litre de brassage dans la nomenclature de la phase 2. Cela n’est pas très pratique.
Avez-vous une solution pour résoudre ce problème ? Ou bien est-ce une limite de Dolibarr ?

2

Bonjour @Patrick
c’est en cours d’implémentation.

voir par exemple ce sujet :

3

Bonjour,
Si vous ne pouvez pas attendre, il y les modules de Patas qui répondent à votre besoin (factory et equipement).

4

Merci pour ces informations.
Je vais attendre la V14. Pour le moment je me contente de réactualiser le prix de revient de temps en temps.

5

Bonjour :slightly_smiling_face:
Je viens faire un test upgrade v14 à v16 mais je n’ai pas l’option sous nomenclature prévue.
ex (voiture super bien conçue…) :

  • un produit voiture et sa nomenclature (4 produits roues)
  • un produit roue et sa nomenclature (1pneu, 1 jante)

je ne trouve pas lors de j’ajout d’une ligne le choix produit ou nomenclature comme dans le screenshot ATM.

Selon ATM ce serait bien dispo (Les nouveautés de la version 16.0 de Dolibarr ERP/CRM - ATM Consulting)
@atm-maxime @atm-benoit (etc :rofl:) une idée?

Ps j’ai bien activé les modules BOM et OF

6

La version 16 n’est pas encore sortie donc il peut y avoir encore des dysfonctionnements

7

@Tonio-APEIF oui j’ai vu ca mais j’étais pressé :rofl: :rofl:
et vu que le message d’ATM date de juin j’ai tenté :innocent:

8

C’est pour l’instant une configuration cachée : BOM_SUB_BOM

2 « J'aime »
9

Bonjour :slightly_smiling_face:
Coool je teste de suite :+1:

10

Bonjour :slightly_smiling_face:
@atm-maxime J’ai un peu testé à l’instant, j’ai l’impression que les nomenclatures en cascades s’arrêtent au premier sous niveau et ne partent pas en cascade à l’infini. Est-ce le cas ?
Merci à vous :+1:

11

Bonjour @dolibarr95,

En v16, il est possible d’ajouter une nomenclature (enfant) dans une autre (parent) grâce à la configuration cachée « BOM_SUB_BOM ». L’onglet « Nomenclature » de la BOM ne permet de visualiser que le premier niveau de nomenclature enfant.

Cependant, si votre nomenclature enfant possède elle même une nomenclature enfant, etc., nous avons ajouté un nouvel onglet « Besoins nets » qui permet de visualiser l’arborescence complète de tous les sous niveaux. Cet onglet propose deux vues (au dessus du tableau à droite), l’une avec l’arborescence de tous les sous niveaux, l’autre avec un regroupement par produits tous niveaux confondus.

Lorsqu’un OF est créé depuis une BOM qui en contient une autre, une case à cocher permet de choisir si l’on souhaite créer un sous OF pour cette sous BOM ou non. Le sous OF apparaît dans les objets liés de l’OF parent. Cette création de sous OF ne se fait pour le moment que pour la sous BOM de premier niveau mais il sera en effet nécessaire à termes que les sous OFs se créent de manière récursive jusqu’au plus bas niveau.

1 « J'aime »
12

Bonjour :slightly_smiling_face:
@atm-thibault super merci pour ces précisions !!!

13

ou pas systématiquement :wink:
vous avez prévu de bosser sur le calcul de réappro ? (sujet qui m’intéresse aussi)

14

Bonjour :slightly_smiling_face:
Perso j’ai dev un module qui permet de gérer les sous nomenclatures en cascades avec gestion des réappro, selon mon responsable achat ca marche bien (il est confiant lui :rofl: …vivement l’inventaire :innocent:).
L’astuce pour moi est simplement en effet une fonction récursive.

C’est un peu de la soupe mais ca marche :rofl: :rofl: :rofl: :rofl:

En gros lors de l’écriture de la nomenclature je précise dans la table si il existe un child (une nomenclature pour ce produit) ou non et lors de l’appel des lignes de l’objet j’ai un truc du genre :

function fetch_recursive($object, &$lignes)
{
    if ($object->lines) {
        foreach ($object->lines as $line) {
            if($line->fk_child == 0){
                $lignes[$line->fk_composition][] = array(
															'type'		=>	'ligne',
															'id'		=>	$line->id,
															'produit'	=>	$line->fk_product,
															'quantite'	=>	$line->quantity,
															'id_composition'	=>	$line->fk_composition,
															'fk_composition'	=>	0
															);

				} else {

					


					$lignes[$line->fk_composition][]  = array(
															'type'		=>	'parent',
															'id'		=>	$line->id,
															'produit'	=>	$line->fk_product,
															'quantite'	=>	$line->quantity,
															'id_composition'	=>	$line->fk_composition,
															'fk_composition'	=>	$line->fk_father->id
															);



					$this->fetch_recursive($line->fk_father, $lignes[$line->fk_composition][]);

				}

			}

		}
		

	}
15

Oui en effet, la génération des sous OF jusqu’au plus bas niveau ne doit pas être systématique. Dans l’idéal, il faudrait pouvoir choisir quels sous OFs doivent être lancés ou non dans les sous niveaux. Il faut voir ce qui est possible en terme d’interface pour que ça reste clair et que ça n’affecte pas trop la performance dans le cas d’une arborescence avec beaucoup de composants et un très grand nombre de sous niveaux…

Concernant le réappro, je ne suis pas sur que cela doit se gérer dans la BOM. En effet, à mon sens, un système de réappro efficace doit compiler dans un écran tous les besoins d’achat de différentes BOM selon les dates de besoin, le délai d’appro, le temps de fabrication, etc. En toute logique il n’y a pas de date de besoin sur les BOMs puisque la notion de date intervient lors du lancement en OF. La notion de date est d’ailleurs un élément manquant à mon sens sur l’écran de réappro standard de Dolibarr aujourd’hui (j’ai besoin de 500 pièces mais peut etre 300 la semaine prochaine et 200 dans six mois ce qui n’implique pas la même gestion du réappro !)

Pour ces raisons, nous prenons pour le moment le chemin d’un module externe MRP (material requirements planning) qui va proposer cette vue consolider de l’ensemble des besoins selon les arborescences des BOMs, les dates de besoin (pour production ou expédition), les durées de fabrication, etc. Les modes de calculs sont complexes et nous allons avancer dans un module externe pour le moment pour peut être le proposer en standard à plus long terme si cela répond aux besoins de la communauté.

16

@atm-thibault pour les of en cascade je pense que pour pouvoir tout gérer sans plomber Dolibarr il faut une fois la nomenclature validée l’archiver et la gérer à plat et pas en sous éléments.

17

Salut,

je reviens sur cette phrase : ça sert à quoi de faire ça ?

Dans tous les ERP que je connais, ça ne fonctionne pas comme ça (pour les nomenclature)

Chaque produit a sa nomenclature → calcul de besoin du premier niveau
si un produit enfant comporte un besoin et qu’il a une nomenclature → on recommence … jusqu’au niveau … et ainsi de suite (généralement on, s’arrête à N niveau pour par que le calcul dur des plombes)
au même titre que des proposition de commande fournisseur, on a à la sortie des proposition de création d’OF.

Il faut juste mettre une vérification qui va bien pour éviter les boucles de nomenclatures à leur création.
Et une « nomenclature par défaut » pour le produit s’il en a plusieurs. (ou un indice, ou un ordre de préférence… bref un truc qui permet d’en choisir une)

C’est quoi l’intérêt de faire des BOM de BOM ? Vouloir lancer une cascade d’OF en une fois à la main depuis un produit père ?
Si c’est ça : il faut faire comme pour le calcul décrit plus haut : si produit enfant = fabriqué → on génère (ou propose) aussi son OF, etc…

ça complexifie énormément le truc de vouloir faire des BOM de BOM dès le départ. non ?

18

oups j’oubliais @atm-thibault :
+1 pour tes propositions sur un calcul des besoins à horizon défini et avec un regroupement (ou pas) des besoins par période (reste à choisir où mettre les règles de regroupement… il y a plein d’écoles pour ça :wink: )

Par contre, prendre le chemin d’un module externe MRP n’est pas pérenne je pense:
OK, ton dv répondra surement à certains qui veulent tout lancer en une fois verticalement, mais ça n’est pas le cas le plus courant.
Pourquoi ne pas intégrer les proposition d’OF au même titre que les proposition d’achat dans le calcul de réappro ? (les prochaines proposition prenant en compte (ou pas) les propositions précédentes non encore validées)

et là, on en serait qu’a du MRP1… sans plannif de ressources ni gestion logistique :wink: #goodoldtime

19

Le nomenclature par défaut existe désormais en v16. Je ne comprends pas bien ta remarque, ce que tu décris ressemble donc bien à un système de sous nomenclatures imbriquées ?!

Nous avions proposé un système qui ressemble à ce dont tu parles d’après moi qui permettait d’ajouter un produit dans une BOM et de pouvoir choisir sa BOM (qui serait préremplie par celle par défaut) le tout sur une seule ligne : https://github.com/Dolibarr/dolibarr/pull/18503. Cela a été refusé au profit de ce que nous avons fait par la suite.

C’est en effet l’idée de lancer une fabrication du produit parent et d’avoir une génération d’OF enfant en cascade. Pour que cela soit efficace, il est nécessaire de pouvoir définir dans les BOMs, les sous BOMs associées. Le système de la BOM par défaut nous semblait bien pertinent aussi et leur utilisation allait dans le sens de la PR que j’ai postée ci-dessus.

Pour la génération des sous-OFs, l’idée étant de ne pas aller vers un système tout ou rien mais plutôt de permettre de choisir les OFs enfants qui se génèrent selon l’état des stocks lors du lancement de l’OF parent.

Je pense par exemple au formulaire de création d’un OF depuis une BOM qui pourrait afficher toutes les sous BOM et précocher la case de génération de sous OFs sur les produits qui n’ont pas de stocks mais permettre de cocher ou décocher ces cases manuellement. A terme, il serait même intéressant de changer de sous BOM sur ce formulaire au moment de lancer la fabrication (d’ou encore une fois l’intérêt d’avoir une autre colonne pour la BOM sur la même ligne que le produit plutôt que ce « OU »)

image

20

Ajouter les besoins d’OF dans le calcul du réappro est en effet une idée mais le problème reste que cet écran de réappro ne prend pas du tout en compte les aspects de date ce qui perd beaucoup de son intérêt. Le système me dit que je dois acheter 1000 produits mais peut être 200 cette semaine et 800 dans six mois, ce qui change tout pour la gestion logistique de stockage, la gestion de trésorerie, etc.

Ce module MRP a pour but d’aller vers cela en ne proposant pas seulement une vue de réappro mais une vue de planification des lancements de fabrication et d’appro selon les dates d’expédition prévisionnelle, les durée de fabrication, les délais de livraison des fournisseurs, etc.

Le choix du module externe vient surtout du fait que cela repose sur des calculs complexes prenant en compte beaucoup de données en même temps (comme tu le dis il y a plein d’écoles pour les règles de regroupement :wink: ) et que nous sommes plus en confort d’avancer de manière autonome pour le moment. Nous ne sommes pas fermer à l’idée de proposer tout ou partie du module en standard dans un futur plus lointain.