Discussion:OF2.0 : Différence entre versions

Version actuelle en date du 11 août 2006 à 19:59

Et l'huile ??

De la meme manière que l'on saisit l'avitaillement en essence, il faudrait prévoir la même chose pour l'huile

Sémantique

Je ne sais pas où placer les rêgles de construction des noms pour les tables. De plus, il me semble qu'on en a déjà parlé sur le forum, mais où ?

--Christophe 16:41, 8 Jun 2005 (CEST)

Unités

Il va falloir choisir des unités pour le carburant (et l'huile ;-)

--Christophe 16:41, 8 Jun 2005 (CEST)

A cause de l'internationalisation, il va falloir prévoir plusieurs unités de mesures avec des tables de conversions, ce qui nous donne des litres, des imperials gallons, des US gallons

L'autre possibilité c'est de se limiter aux litres qui est l'unité internationale des volumes ( en aviation aussi ?) --Stéphane

Eh eh ! C'est plus compliqué que cela, il faut aussi prévoir des unités de poids. Je ne sais pas si c'est utilisé en aviation légère mais c'est utilisé dès qu'on se met à couler des quantités raisonnables et que parler en tonnes pour le carburant est courant. En fait, l'essencier coule toujours des litres (débitmètres) et facture en tant que tel, mais dans l'avion l'autonomie est déterminée en fonction du poids. En effet, 10.000 L ne font par le même poids (et donc la même "énergie") qu'il fasse moins -20°C ou +40°C (à cause de la dilatation).

Donc en fait, je me pose la question, s'il ne serait pas intéressant de donner la possibilité de saisir les quantités dans l'unité souhaitée, et de stocker l'unité en plus de la quantité. C'est un peu dans le même état d'esprit que pour les heures de vol : ainsi on ne souffre pas de problème d'arrondi. La quantité saisie est bien la quantité enregistrée.--Christophe 12:38, 10 Jun 2005 (CEST)

Ça a l'air très compliqué tout ça d'autant plus que ce n'est pas dans un aéroclub on n'est pas près de faire des pleins de plusieurs tonnes de carburant. Donc si comme tu le dis tous les débimètres du monde sont en litres, on fixe les litres comme unité de mesure. Et si jamais Air France désire utiliser OF pour sa flotte, on facturera un patch de pour avoir les mesures en tonnes. --Stéphane

Je l'attendais ;-)

Oui mais mon exemple perso veut dire qu'il y a peut-être d'autres systèmes dans d'autres endroits...--Christophe 18:31, 10 Jun 2005 (CEST)

C'est sûr que l'on peut trouver tout un tas de systèmes de mesure des volumes "exotiques", mais quand tu fais le plein de ton airbus, tu demandes à ton pompiste 1000 litres ou 700 tonnes de kéro ? (je sais j'ai pas tenu compte de la température :-)

Donc je pense qu'il faudrait dans la partie admin du club spécifier quelle est l'unité de mesure pour l'essence et l'huile. Par contre je serais pour le volume soit stocké dans la bdd en litre qui est l'unité de mesure internationale pour les volumes. Cela passera donc par une moulinette de conversion avant stockage dans la bdd

Voilà quelques unités de mesures des volumes

1 Litre = 33.824 ounces = 1.0570 Quarts = 0.2642 Gallons = 0.2200 Imperial Gallons

--Stéphane

Je demande à mon pompiste un volume dans l'unité utilisée par son pays (donc dans 99% des cas des litres mais pour info aux états-unis ils ne connaissent pas les litres).

Autant je pense qu'il est intéressant de se poser la question "à quel niveau bloque-t-on l'unité ?" (plein, avion ou club), autant dans tous les cas, je suis contre une conversion en litre qui amène une inexactitude dans le traitement de l'information. Je ne pense pas que raisonner en terme d'unité internationale soit la bonne tactique, c'est un peu comme dire aux asiatiques de laisser tomber leur langue pour passer à l'informatique, alors que justement l'informatique peut très bien s'adapter aux particularités. Si on dit que la quantité enregistrée est des galons, pourquoi convertir en litres ? A partir du moment ou OF aura l'info que c'est des galons, il pourra toujours proposer une conversion à posteriori.

Donc je propose plusieurs solutions. Soit :

• créer un champ dans la table club définissant l'unité de volume
• créer un champ dans la table avion définissant une unité de volume (pour chaque avion donc)
• créer un champ dans la table contenant les pleins pour indiquer l'unité utilisée pour faire le plein.

La dernière solution à ma préférence. Elle est très simple à mettre en oeuvre. Pour additionner les quantités, il suffit de faire une requête qui distribue les quantités dans des colonnes en fonction de l'unité utilisée, puis d'additionner les colonnes, de convertir le résultat de chaque colonne dans l'unité d'affichage souhaitée, et d'additionner les résultats.--Christophe 18:38, 11 Jun 2005 (CEST)

Bargraph de potentiel

Jusqu'à présent je ne comprenais pas pourquoi je trouvais la représentation en bargraph non intuitive (sauf lorsqu'on a compris ;-)

Cela vient, il me semble du fait que la jauge se vide (de la droite vers la gauche) plutot que de se remplir (de la gauche vers la droite)

Ou alors, il faudrait pour le potentiel utilisé mettre la couleur de fond pour bien montrer qu'il n'est plus là justement.

Bref, si l'idée du bargraph me parait excellente, je pense qu'il faudra éventuellement affiner la représentation pour qu'elle soit compréhensible du premier coup et sans explication. Sinon, je suis sûr qu'il y aura des pilotes qui diront : "je croyais que".

Une autre méthode, consisterait en une couleur unique par barre, qui passerait du vert au rouge au fur et à mesure que le potentiel diminue.

Une autre chose, qui permettrait peut-être de mieux comprendre est de me mettre les barres verticales (plutot qu'horizontales) : cela correspondrait plus à une jauge d'essence, donc à un potentiel.

--Christophe 16:40, 8 Jun 2005 (CEST)

Ordinateur autorisé à saisir les vols

Joël avait écrit :

> Pour la convivialité dans le club je préférai que la page la plus souvent visible soit la page du planning de réservation. Ceci ne doit pas être le cas lors d'une connexion standard ou c'est celle du login + mdp qui doit apparaître

Tout à fait. Mais attention : il faut considérer que la saisie des heures de vols doit pouvoir fonctionner sans avoir à rajouter un module particulier côté club pour identifier l'ordinateur. Or aujourd'hui, pour l'armoire à clé, c'est comme cela que nous envisageons les choses : avec un sésameur qui envoie un message à OF pour dire "je suis là, retiens mon adresse IP". La question est : peut-on créer un système suffisamment fiable pour que l'ordi du club et lui seul soit reconnu comme ordinateur autorisé à saisir les vols ? Je penche vers un système faiblement sécurisé à l'aide d'un simple login/mdp (comme pour le mode visiteur). Pour que les gens ne le connaissent pas, il suffit que le gestionnaire du club crée avec le navigateur un bookmark avec enregistrement du login et du mdp. Une autre solution consisterait à permettre au gestionnaire du club d'aller dans un menu spécial de l'admin pour dire : "retiens cet ordi comme autorisé à saisir les vols". Et de ce fait, OF placerait un cookie particulier côté ordi.

Je suis favorable à l'un (voir au deux) systèmes, car cela évite d'avoir à créer un programme (comme le sésameur). D'autant plus qu'on reste dans le cas d'une utilisation somme toute classique et par conséquent qui doit être ouverte à un maximum de configuration.

J'aimerais qu'on garde la philosophie : "installation logicielle <=> installation matérielle". (le <=> veut dire si et seulement si (vieux souvenirs... pff...).

Par contre pour la gestion des clés, du fait l'obligation d'avoir une interface logicielle pour dialoguer avec l'armoire, la sécurisation est plus élevée.

J'aime bien la 2° solution : menu admin -> cookie particulier. ça permet d'autoriser de façon simple plusieurs ordi : celui en libre service au club, mais aussi celui de la secrétaire, du trésorier chez lui, au moins deux postes qui auraient à accéder aux fonctions "Flights" (la liste est pas exhaustive)--Jdepardieu 17:53, 4 December 2005 (CET)

Cette deuxieme solution me plait aussi, mais pour identifier l'ordinateur qui est physiquement relié à l'armoire a clef, plutôt d'utiliser l'adresse ip je proposerais d'utiliser l'adresse mac de la carte reseau. Elle a l'avantage d'identifier de maniere unique la carte reseau, c'est une adresse qui ne peut etre changée. Une adresse ip peut changer à chaque connection, il faudrait donc verifier si l'adresse du pc relié a l'armoire et toujours la même que celle référencé dans la "table des autorisations".--Utopie 21:02, 4 December 2005 (CET)

Table des tarifs

Pour la colonne type de vol, il faudrait pouvoir y mettre les types sérialisés, cela permettrait de créer des tarifs particulier pour des types cumulés (IFR en montagne) bien que je n'en vois pas trop l'utilité. Mais j'ai un problème : la double doit-elle être considérée comme un type de vol au sens défini plus haut. Auquel cas, faut créer ce type en plus des IFR, montagne, etc. Mais ça me gêne, car le gars peut très bien ne pas mettre double comme type de vol. Donc il faudrait trouver un système pour lier un type à certains paramêtres (présence d'un instructeur ici). Si vous avez une idée...

Sinon, pour les tarifs qui changent en fonction du type de vol, il y a une autre voie que la sérialisation dans le champ "type de vol" : faire l'addition des prix pour chaque type. Ainsi y'aurait un tarif de base (l'avion). Si on fait de la double, on rajoute x euros, si on fait de l'IFR, y euros. Mais le problème c'est que cela ne permet pas au club de faire des ristournes sur certains cumuls. Bref, je ne sais pas trop.

Vérifications comptables

• Il serait bon de générer un N° de pièce comptable permettant d'identifier le mouvement (Vol/versement/transfert entre compte adhérents, ...) Cela permettra une validation plus simple également au trésorier, et un élément concret au membre qui vient de faire la saisie.
• D'autre part, si OF peut générer un fichier au format EBP/CIEL ou autre pour transfert vers le logiciel comptable, vous aurez une solution qui intéressera encore plus de clubs.....

A+

--Hthepaut 18:12, 20 Jul 2005 (CEST)

• Concernant le N° de mouvement il est prévu dans la table Accounting_entry_Table par contre il n'était pas prévu de le rendre visible.

Pourriez-vous expliciter comment cela peut aider le trésorier ? (afin de concevoir une interface qui l'aide réellement ;-)

Pour le membre, je pensais qu'une date suffisait à tracer facilement une écriture.

• Pour l'export, c'est le but recherché (sinon cela ne sert à rien de faire de la gestion de comptes ;-)

--Christophe 10:35, 21 Jul 2005 (CEST)

Le N° de pièce permettra une traçabilité du paiement entre le membre et le trésorier. ce N° peut être reporté sur le chèque lui-même ou tout autre support (enveloppe, ...) qui servira à faire parvenir le mode de paiement jusqu'entre les "mains" du trésorier.

Ce N° peut également servir ultérieurement lorsque nous aborderons les annulations de saisie de vol. Car il y aura des erreurs de saisie (c'est inévitable). Le gestionnaire pourra alors demander à supprimer directement le vol N°xxxx, et resaisir en lieu et place de l'adhérent tête en l'air...Si vous n'avez pas prévu cette fonctionnalité, pensez-y.

--Hthepaut 16:51, 21 Jul 2005 (CEST)

Pour la traçabilité du paiement, on pense plutôt utiliser le numéro lié au paiement (PAYMENT_NUM qui se trouve dans la table Accounting_entry_Table). Ainsi si c'est un paiement par chèque, alors on renseigne le numéro de chèque (on peut également y mettre le nom de la banque). Au dos du chèque, j'ai plutôt l'habitude d'y voir figurer le numéro du compte du pilote.

Néanmoins, le fait de faire figurer le numéro de mouvement peut aider au rapprochement. Mais je ne suis pas sûr que cela n'entrainera pas d'autres erreurs de rapprochement dues à la focalisation sur le pointage du mouvement et donc plus de vérification sur le montant ni sur le destinataire.

Concernant les vols, on a prévu la gestion des vols non saisis (vols oubliés). Pour l'annulation ou la modification de mauvaises saisies on s'oriente vers un mode "brouillard" qui permettrait à l'utilisateur (ou au gestionnaire) de modifier ses saisies jusqu'à une validation ultérieure.

L'avantage du mode brouillard par rapport à une saisie sans retour possible est double :

- limiter le nombre de champs à renseigner (puisqu'il y a facilement la possibilité de revenir en arrière) et de validations à effectuer (sur aéro21, c'est un peu lourd : faut valider sur F8 puis sur F4, ou l'inverse, je ne sais plus).

- permettre à l'utilisateur de modifier facilement a posteriori sa saisie ! (par exemple, une fois rentré chez lui, il se dit : zut ! j'ai oublié ceci ou cela...) ou a un gestionnaire de bas niveau (mécanicien, instructeur) de corriger facilement une saisie sans avoir à passer par un gestionnaire de niveau supérieur (secrétaire, trésorier).

Par contre, une fois que c'est validé, il n'y aura plus de modification possible.

M. Mme Mlle !

Je m'élève vigoureusement contre le projet d'enregistrer dans OF les potentialités matrimoniales des femmes, sans qu'il en soit de même pour les hommes.

Le fait d'indiquer, même sous couvert de pudeur, le statut matrimonial (Mme ou Mlle) d'une femme est une discrimination sexiste inacceptable.

Est-ce qu'il est prévu de faire de même pour les hommes . (Monsieur et Mondamoiseau ?).

J'ai l'air de rigoler en disant ça, mais je pense que le problème est sérieux, et même si ce n'est pas notre rôle de faire évoluer la société et ses pesanteurs, il serait bon que nous adoptions une attitude neutre de ce point de vue.

--drpiquouze 20:46, 11 August 2006 (CEST)