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