Talk:OF2.0

Et l'huile ??

De la meme manière que l'on saisie l'avitaillement en essence, il faudrait prevoir 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 faloir prevoir plusieurs unitées de mesures avec des tables de convertions, 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ée enregistrée.--Christophe 12:38, 10 Jun 2005 (CEST)

Ca a l'air tres compliqué tout ca d'autant plus que c'est pas dans un aeroclub on n'est pas prés de faire des plein de plusieurs tonnes de carburant. Donc si comme tu le dis tous les débimetres du monde sont en litres, un fixe les litres comme unitée 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 sur que l'on peut trouver tout un tas de systeme de mesure des volumes "exotiques", mais quand tu fais le plein de ton airbus, tu demande a ton pompiste 1000 litres ou 700 tonnes de kero ? (je sais j'ai pas tenu compte de la temperature :-)

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

Voila quelques unites 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.

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 comptable

• 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 interressera encore plus de club.....

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)