Bonjour Brendan,

 

Voir mes réponses en rouge ci-dessous.

En PJ des tests fait ce matin sur le module liste à servir avec base DEMO.

 

A+

 

-----Message d'origine-----
De : franciaflex-magalie-devel-bounces@list.forge.codelutin.com [mailto:franciaflex-magalie-devel-bounces@list.forge.codelutin.com] De la part de Brendan Le Ny
Envoyé : lundi 22 juillet 2013 19:46
À : franciaflex-magalie-devel@list.forge.codelutin.com
Objet : Re: [Franciaflex-magalie-devel] Nouvelle révision 315

 

Bonsoir,

 

Le 19/07/2013 15:37, REVOL Bernard a écrit :

> Pour cette semaine 30 il va falloir nous consacrer du temps pour corriger les petits bugs rencontrés sur cette nouvelle version afin de passer en production l'ensemble des modules d'ici la fin de la semaine.

 

Je vais me répéter mais les versions que je vous donne sont là pour vous permettre d'ajuster l'environnement de production et non d'utilisation en production. C'est un risque que vous prenez.

ON ASSUME !!!!

> - (1) Je t'ai envoyé le résultat des premiers tests de cette version en début de semaine : il y a des petites choses à corriger rapidement afin d'installer en production cette version. (voir si mes remarques sur la base de données sont pertinentes ou pas).

 

La remarque est pertinente mais tel que c'est fait, cela simplifie le développement. Faire le changement prendrait du temps et il n'y a pas de valeur ajoutée significative de mon point de vue.

Pourquoi cela simplifie le développement d'ajouter ces tables intermédiaires ?? je ne vois pas mais tu dois avoir tes raisons…

Cela implique de les gérer lors de l'interface entre Magalie et BaaN :

ex :lors de l'insertion d'un enregistrement dans la table deliv_reque_artic_stora_movem d'un mouvement lié à une liste à servir le trigger qui va inserer un enregistrement equivalent dans une table de BaaN ne peut pas etre aussi simple que le trigger de récupération des enregistrements de storage_movement.

 

Idem pour le trigger de suppression de l'enregistrement dans BaaN qui doit supprimer l'enregistrement équivalent dans Magalie…

 

Bref rien est impossible mais avoue que gerer des tables qui n'ont pas d'utilité dans la base de données ce n'est pas très esthétique !!

 

> - (2) Validation de la base de donnée

 

Pour moi, le dernier fichier sql que j'ai donné est bon et, à moins d'un changement majeur, il ne devrait pas changer.

 

> - (3) Installation de la version avec les corrections demandées : le module Kanban étant d'ors et déjà en production, il faut que cela soit transparent pour les magasiniers (juste expliquer le fonctionnement de la touche F4 nouveauté de cette version).

 

Il n'est pas censé être en production.

 

Si vous me demandez des corrections, je les ferai. Je ferai en sorte que l'interface ne change pas trop, mais si le besoin l'exige, je devrais faire les adaptations nécessaires.

Pas de souci par rapport à ça.

 

> Ces 3 points devront être réalisés lundi soir de manière à démarrer en prod. le mardi matin.

> 

> -(4) Tests du module gestion des toiles (Sorties Toiles)

> -(5)  Envoi des demandes de corrections si nécessaire.

> -(6) Correction des anomalies par Code Lutin

> -(7) Envoi d'une version corrigées pour mise en prod.

> 

> Ensuite on devrait procéder de la même manière pour les modules : Réceptions fournisseurs/Stockage des toiles, Gestion des Listes à servir.

 

Je veux bien travailler en fonction de vos priorités (par module), mais je ne peux rien garantir sur les échéances. En effet, elles dépendent d'une part, du temps que vont me prendre les corrections demandées et d'autres part, de mes disponibilités (j'ai des contraintes sur d'autres projets).

 

> Si on considère que l'on traite un module par jour (étapes 4 à 7), nous devrions avoir une version "testée et approuvée" jeudi 25/07 au plus tard.

 

Signales-moi les corrections à effectuer au plus vite et je les ferai au plus vite, selon mes disponibilités.

 

> Il nous restera une semaine complète d'utilisation par le magasin avant la fermeture de Fx (3 semaines : 32/33/34), pour corriger les tous petits soucis éventuellement remontés par les utilisateurs.

> Pour Code Lutin de fournir une vraie version de production et de paramétrer un environnement de test avec les données de BaaN.

 

Dès l'instant où vous validez que le logiciel est terminé, on peut vous livrer la version finale le lendemain. L'idéal serait d'y arriver avant la fermeture de Franciaflex.

 

J'ai mis sur démo une nouvelle version qui corrige les problèmes remontés sur le module Kanban et le module Transfert de stock.

 

Peux-tu retester ?

OK pour les corrections apportées – les bugs sont corrigés.

 

P.S : le changement majeur que j'évoque n'a rien à voir avec la gestion des priorités des prélèvements, effectivement ces règles n'ont que peu changées depuis le début du projet. Le changement que j'évoque concerne le fait de passer d'une gestion par ordre et réservation du stock nécessaire au prélèvement à une gestion en temps réel (où on prélève dans le stock et fonction du stock disponible à l'instant t)

 

--

Brendan Le Ny, Code Lutin

bleny@codelutin.com

(+33) 02 40 50 29 28

_______________________________________________

Franciaflex-magalie-devel mailing list

Franciaflex-magalie-devel@list.forge.codelutin.com

http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/franciaflex-magalie-devel