Le 24/04/2013 17:31, REVOL Bernard a écrit :
/Puisque cela convenait quand nous en avions parlé, je suggère que toutes les listes soient gérées ainsi. Cela fera une inconnue de moins à gérer pendant les tests. Je pense donc qu'on ne devrait pas avoir cette colonne dans les vues./
*Est-ce que ce mode de fonctionnement est valable uniquement pour les tests ? la gestion de ces deux méthodes sera effective en production ?*
Non, ce sera comme ça en production. Toutes les listes seront traitées avec une personne affectée à la fois.
*Je trouve plus logique de notifier la notion de FULL plutôt que OCCUPIED.*
*Qu'en penses tu ?*
OK. C'est renommé.
Cas d'un article sans stock disponible : mettre message plus explicite : ARTICLE SANS STOCK.
J'ai changé le message.
. Mémorisation dans table Magalie.
J'ai créé la table UNAVAILABLE_ARTICLE. Comme on ne peut jamais savoir à partir de quand un article est de nouveau disponible, j'ajoute une ligne quand Magalie constate un article sans stock, je retire la ligne s'il y a de nouveau des stocks mais je ne tiens jamais compte de la valeur.
Le kanban va être mis de côté afin d'être traité plus tard : Un programme BaaN scrutera les entrées en stocks (réceptions Ordre d'Achat ou Fin de Fab d'un Ordre de Fabrication) pour les articles correspondant aux kanbans en attente. Dès que le stock sera > 0, l'information sera passée au magasin.
Du coup, l'utilisateur pourra refaire sa demande, et Magalie permettra le prélèvement, à cette occasion, la ligne dans UNAVAILABLE_ARTICLE sera supprimée.
non servi pour le proposer plus tard
Ce que nous avons fait pour avoir cet écran : Saisie qté à 5 puis bouton ANOMALIE. Ensuite bouton TERMINER Voici le rapport magalie ci-dessous qui en résulte Emplacement en erreur OK mais il faut préciser la ref article car dans un emplacement plusieurs articles différents peuvent être stockés.
C'est corrigé.
Ensuite nous avons réessayer de traiter le même article : Erreur cet article n'est pas disponible. Cela signifie que le stock de cet emplacement pour cette référence n'est plus proposé. OK
C'est ça.
mais comment fait on pour rendre à nouveau dispo cet emplacement en erreur. Est-ce que c'est la suppression de l'enregistrement dans la table LOCATION_ERROR qui va régler ce problème.
C'est exactement ça. J'ai fait cette précision dans le documentation du schéma. C'est à Franciaflex de retirer la ligne lorsque l'écart de stock a été corrigé.
LISTE A SERVIR Pas de menu proposant le choix du type de liste (à prévoir vue dans schéma): LOT DE FAB ATELIER_LF ... Voir CR de la réunion téléphonique du 10/04/13.
C'est fait. J'ai ajouté dans l'entête de la liste un champ listType. On propose à l'utilisateur de se lancer dans un des différents listType connus.
L'information de la liste en cours de traitement n'apparait qu'au traitement du premier article, pourquoi ne pas conserver cette information pour l'ensemble des articles de ladite liste.
En fait, ce qui apparaît c'est pour signifier un changement d'affectation uniquement. J'ai ajouté l'affectation courante sur la page de demande d'article.
D'après la règle de prélèvement correspondant à cet article, l'emplacement ne devait pas être celui-ci mais le B24. Emplacement non fixe (par rapport au paramétrage de l'article) qui avait une quantité inférieure à l'emplacement proposé ci-dessus.
J'avais mal compris le sens du booléen. En fait pour moi false = les emplacements fixes sont en derniers. J'ai corrigé pour que false signifie « ignorer les emplacements fixes et considérer les autres critères de priorités ». J'ai fait le test avec ce qui est montré sur la capture d'écran et j'obtiens le bon résultat.
Le deuxieme emplacement aurait du etre le U01 C03 au lieu du U01 B02 car le premier a moins de stock que le second.
J'ai trouvé un bug qui faisait qu'en fait, les emplacements étaient montrés dans n'importe-quel ordre malgré le tri que j'avais fait en amont. C'est corrigé.
Dans la table des mouvements de stocks (confirmés) peut-on avoir un champ qui dans le cas d'un traitement de liste à servir contienne l'id de la liste ?
C'est le cas, mais l'information est ailleurs. Il faut regarder dans les tables DELIVERED*. On peut retrouver toutes les associations entre élément de la liste à servir et l'ordre correspondant.
Si une liste à servir est demandée par un utilisateur A mais en cours de préparation celui décide d'arrêter avant le traitement complet de la liste. Liste reprise par un autre magasinier B qui lui va la traiter jusqu'au bout: Dans l'affichage des mouvements de stock prévus non confirmés, les mvts prévus pour l'utilisateur A restent. Comment disparaissent-ils ?
En fait, l'utilisateur ne doit jamais s'arrêter pendant le prélèvement d'un article. L'interface ne le lui permet pas. Il doit finir son prélèvement et confirmer. Du coup, l'utilisateur ne peut pas s'arrêter en cours de traitement d'une liste sans cliquer sur « changer d'activité » qui apparaît entre chaque élément de la liste (il a donc plusieurs fois l'occasion de changer au fur et à mesure qu'il traite la liste) mais quand il appuie sur le bouton la liste est repassée en PENDING. Pour arriver là, il a forcément dû confirmer son ordre, il ne peut donc pas rester d'ordre en attente.
Statut liste à servir = PENDING mais quand un magasinier avec tous les permis se connecte et demande le trt d'une liste il a l'écran suivant :
Oui la liste est en PENDING mais tous les articles dedans sont en ruptures. Désormais, ils sont reportés dans la table UNAVAILABLE_ARTICLE. On pourrait changer l'état de la liste vers un état INCOMPLET mais il faudrait définir pour cela comment on quitte cet état. -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28