Entrepôt stock non vendable

Hello,
J’utilise les stocks pour générer des commandes de réappro automatiques. Le soucis c’est que si le stock physique et positif (dû au stock non vendable), je n’ai pas d’alerte sur un stock manquant. Donc je ne peux pas utiliser la fonction réapprovisionnement avec des stocks non vendable dans l’état.

ça doit être paramétrable ça:
regarde le dernier pavé de la config du module stock


Dans ce bloc ?

Le stock disponible apparaît comme information en bout de ligne lorsqu’on saisit un produit enregistré dans une proposition commerciale ou une commande. Et on peut penser qu’on a les produits disponibles à la vente alors qu’ils sont déjà réservés pour une autre commande.

effectivement c’est également un soucis chez moi.

Bonjour à tous, c’est un problème que je rencontre également. Je définis un entrepot par commande client et y transfère les produits (y compris physiquement) pour les réserver. Lorsque mon entrepot de la commande contient tous les éléments de la commande, j’expédie.
Une gestion de commande chez nous peut durer 2-3 mois.
Mais en pratique, lors des réapprovisionnements, ces stocks interfèrent avec la décision d’appro.
Une solution consiste à utiliser le module ReStock. On fait des restocks globaux et les quantités à commander intègrent bien les stocks physiques, les commandes fournisseur déjà en cours. Le seul hic, et c’est vraiment dommage, c’est que les réceptions partielles ne sont pas prises en compte…
Il suffirait que cela fonctionne pour que (pour ma part) je puisse avoir une confiance TOTALE dans la proposition de « ReStock » générée pa rle module. @defrance, si vous m’entendez :pray: :pray:

1 « J'aime »

Merci @Arre !
Cas supplémentaires au cas indiqués dans ta brillante request : les produits alloués à une commande qui doit être expédiée ultérieurement et qui ne sont donc plus disponibles à la vente.
Dans l’idéal il faudrait que les produits puissent être décomptés du stock disponible mais qu’on puisse néanmoins faire des expéditions depuis cet entrepôt d’un nouveau statut.
Encore merci !

@gbbn ça je ne sais pas trop:
il n’est pas plutôt préférable de valider une expédition sans la clôturer ? (en paramétrant la décrémentation de stock sur les expéditions validées bien sûr)

Merci vivement.

Salut Arre,

Dans le cas où le client a passé sa commande et souhaite être livré en plusieurs fois ou si c’est du stock pré-vendu (pas encore reçu mais ne doit surtout pas sortir pour les autres)

Autre cas, un peu comme GLPI : tenir un inventaire des articles achetés et vendus par l’entreprise qui sont utilisés en interne (papier A4, imprimantes, pcs portables, etc…) non ?

Merci pour cette request et ce cas de figure épinglé !

Salut @Arre
As tu eu un retour par rapport à ton message sur github ?
Brice.

Salut @Brice1 ,

Non, et pour cause: ça ne fonctionne pas en mode « liste au père Noël ».

En gros, voici comment ça peut aboutir:

  • un dev qui travaille sur le core, travaille justement sur ce sujet, du coup, il pourrait intégrer tout ou partie de la demande en même temps.
  • un dev qui bosse sur un module, fait la même chose
  • un utilisateur qui a les compétences en a besoin, le code et le propose (en PR dans le core ou sous forme de module gratuit/payant)
  • un (des) utilisateur(s) qui n’ont pas les compétences le font développer et le partagent (PR dans le core ou module gratuit/payant)
    etc…

En premier lieux, tous les intéressés devraient se manifester sur Github.
Ensuite, il faut trouver une piste listée ci dessus, sinon ça peut prendre lonnnngremmmppppsss ou ne jamais voir le jour.

Bonjour @Arre
Justement ce fil de fiscution fait parti des propositions en terme de gestion et d’exploitation des magasins
Proposition des états de magasins si cel apeut etre fait en dev
1- Un état Supplier receptions Gestion des receptions de produits livrée par des fournisseurs, mais avec possibilité d’etre valorisé. Impossible de faire des ventes dans ce magation, possible de faire des opératiosn de transfert vers d’autres magasins.
2- Un état Internal company use Gestion des produits et des services ‹ en stock › mise à la disposition de l’entreprise et qui peuvent etre imobilisable mais impossible de les avoirs dans le stock generale et impossible de passé des facturations dans ce magasin.
3- Un état Product sold awaiting delivery Gestion des produits déja facturé et soit livrée partiellement, soit en attente de complement pour livraison chez le client.
4- Un état Ouvert (uniquement mouvement interne) Gestion des produits de leur valorisations, mais impossible de vendre dans ces magasins déjà le cas
5- Un état Ouvert (tous les mouvements) Uniquement des magasins de vente toutes capacité donc gros et détaille déjà le cas

Cert serrait peut etre utile d’avoir des états de magasin uniquement pour la vente en gros et la vente en détaille
Merci

C’est un sujet qui m’intéresse puisque je suis dans ce cas avec la gestion de produit non vendable (cassé / abimés / a destination du marketing / etc. )

J’ai du temps dev à disposition (mais qui est déjà bien occupé), je vais certainement rajouter ça dans la liste des points à aborder (mais c’est dans le bas de la pile des priorité à ce jour chez nous).
Mais je n’ai aucune idée du quand ce sera regardé.

Je note la requête dans le gitub en tout cas.

1 « J'aime »

il suffit pour l’instant de créer un dépôt « réception fournisseur » et de l’interdire à la vente. (en attente de rangement, contrôle qualité, etc…) : ce stock doit quand même être pris en compte dans le calcul du réappro donc l’état actuel convient.

Comme déjà expliqué : la logique de dolibarr actuelle veut que ça soit une expédition validée, non clôturée.

Pourquoi ne pas créer simplement 2 dépôts ?
D’un point de vue ergonomie, il faudrait alors que les tiers et/ou les utilisateurs soit assignés à des dépôts. Il faudrait alors gérer des droits sur les dépôts. (mais on n’y est pas encore)
Il faudra également que le calcul des réappro autorise de prendre en compte ou non certains dépots et de créer non seulement des commandes fournisseurs, mais aussi des OF ET des proposition de mouvements internes. (par exemple : on n’achete jamais sur le dépôt « vente au détails » mais il est approvisionné par le dépôt « vente en gros »; cas identique pour des magasins avec centrale d’achat / entrepot centralisé interne à la structure)

Il est tres facil d’interdire l’exploitation d’un magasin pour la vente, mais aussi fort possible qu’un collaborateur par inadvertance fasse cette erreur (cas vécu)

Oui sa c’est connue mais donnée plsu de marge de manoeuvre et aussi important tout en gardans une lisibilité plus clair

C’est déjà ce qui est mis en exploitation

Il faud précisé que mon avis préssedent viens d’un condencé des idées émisent en forme de proposition dévolution coté dev core pour une amelioration ce qui rendra notre ERP/CRM plus interressante et facilitera la tach ea plus d’un

Bonjour à tous,

Je me retrouve également dans ce cas.
Nous avons de la perte produits (détérioration) et que nous sommes amenés à jeter (pas de reprise de la part du fournisseurs).
De même, nous utilisons parfois certains produits pour l’entreprise (bombe anti-mouche par exemple).

La proposition de stocks « isolés » fait sens, mais je pense également au côté comptable.
L’utilisation de produits en interne, ou les cas de perte, correspondent à des comptes comptables.
Cela afin de valoriser le stock, et non pas de le considérer comme une perte sèche (ou nous pourrions finalement faire un mouvement de stock manuel).

Peut-être qu’un onglet « transfert en perte » ou « utilisation en interne » que l’on peut associer à des comptes comptable, pourraient faire sens. Cela gérer sous le module stock.
A l’image de la correction de stock (mouvements de stock).

C’est une idée, je ne sais pas si cela peut faire sens ?

Merci en tout cas pour la mise à disposition et l’amélioration perpétuelle de cet ERP, c’est vraiment top.
Belle journée,
Marion

Bonjour Marion.
De notre côté pour gérer les produit en perte ou les produit utilisés par mes collègues, nous avons créer plusieurs entrepôt (entrepôt perte, entrepôt commercial XXX pour matériel de demo, etc) cela permet de suivre le stock comptable réel. Cette solution a été validé par notre expert comptable/commissaire au compte.
Malheureusement, la fonction « stock non vendable/pour utilisation interne » ne fonction pas car le stock de ces entrepôts est tout de même utilisés pour la fonction réapprovisionner dans le module produit alors qu’il ne devrait pas. Probablement juste le select PHP à modifier dans le code… Je m’y pencherai quand j’aurai un peu de temps pour soumettre ce pull sur github.
Cdlt.
Brice

1 « J'aime »

Bonjour @Brice1,

Ce serait en effet une très bonne idée pour la gestion des réapprovisionnements.
Bonne journée

Sterwen