OF2.0

Jump to: navigation, search

La "roue OpenFlyers" se compose de :

  • la résa
  • la gestion des membres
  • la gestion des vols
  • la gestion des comptes pilotes
  • la gestion de la mécanique

La résa est présente depuis le début. La gestion des membres fait son entrée dans la version 1.2 avec notamment la gestion des qualifs et l'ajout de champs supplémentaires. Elle nécessitera l'ajout de nouveaux champs (comme le sexe (ou plus pudiquement : M., Mme, Mlle), l'âge (plus pudiquement : la date de naissance) et les dates d'obtention des qualifs) pour répondre aux critères permettant d'établir des statistiques pour la DGAC.

On se penche donc tout naturellement vers :

Spécification gestion des vols

Champ d'application

Attention, dans un premier temps, nous ne nous concentrons que sur la saisie des vols et pas sur la mécanique (la mécanique, se sera la deuxième quinzaine ;-) Par conséquent, les éléments notés en italique sont là pour mémoire.

Les saisies sont "prévalidées" par javascript au moment de la saisie (cela évite un moulinage inutile par échanges http) puis validées par php (on suppose que les éléments reçus en post ou get data peuvent être truandés.

Principales fonctions

  • Réservation -> OF1 : modifications suite à l’implémentation de la planche de vol
  • Ouverture du vol : récupération des infos de la réservation et mise à jour
  • Fermeture du vol : mise à jour des bases de données compta et avion

Ajout à la table parameter

La présence ou non de la gestion des vols se fait comme pour les autres options par l'interrogation de la class parameter.class.php qui regarde l'état de la table parameter. Ainsi :

  • CODE='FLIGHT'
    • if ENABLED='1', we have to consider Flight
    • INT_VALUE can have 2 values :
      • 0 : complete filling process (open and close flight forms)
      • 1 : only close flight form should be fill

L'autorisation réelle de saisir un vol est donnée par le bit adéquat (voir ci-dessous)

Exemple :

  • si INT_VALUE=0, avec le bit d'autorisation de saisie de vol accordé à tout le monde : alors le cheminement complet est activé. Avant de partir en vol, chaque membre du club ouvre le vol et au retour chaque membre cloture le vol
  • si INT_VALUE=1, avec le bit d'autorisation de saisie de vol accordé à tout le monde : il n'y a pas d'ouverture de vol, mais au retour de son vol, chaque membre doit renseigner les éléments liés à son vol
  • si INT_VALUE=1, avec le bit d'autorisation de saisie de vol restreint au secrétaire : le club ne fait pas confiance à ses membres pour saisir les vols, c'est donc un secrétaire qui tous les jours (par exemple) saisie l'ensemble des vols à l'aide du planche papier ou de coupons de vols.

Ajout au champ profile.PERMITS

  • bit 12 (4096) : allowed to fill flight form (open and/or close forms according to the "FLIGHT" parameter) for himself
  • bit 13 (8192) : allowed to fill flight form (open and/or close forms according to the "FLIGHT" parameter) for the others
  • bit 14 (16384) : allowed to check correct flight form filling

Restriction des terminaux

Une discussion est ouverte sur la méthode permettant de restreindre à certains terminaux la possibilité de saisir des vols. Le but est de n'autoriser, par exemple, la saisie des vols que depuis un ordinateur au club.

Modifications partie "réservation"

Tout ce qui concerne la modification des réservations (et donc calcul des potentiels restants compris) n'entrent pas dans le cadre de la planche de vol.

Dans un premier temps, pour y accéder il suffira d'accéder au "gestionnaire des vols" et de cliquer sur un menu

Pour la convivialité dans le club, il est préférable 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. Il faut donc trouver le moyen de reconnaître une connexion particulière (ceci est aussi applicable en cas de gestion de clé)

Les éléments à rajouter dans la réservation sont :

  • Le clique sur une réservation dans les 30 mn précédentes ouvre automatiquement la fenêtre de saisie.
  • Possibilité de voir les avions "en l'air"
  • Ajout dans la saisie de la réservation des renseignements complémentaires type de vol
  • Ajout dans la saisie de la réservation des renseignements complémentaires type destination

Reservation.png

  • Affichage des bargraphs

Bargraphs

L'attrait essentiel suite à l’ajout de la saisie des vols est de suivre le potentiel des avions en temps réel. Pour cela une indication style bargraphe me semble appropriée.

Nota : pour que le potentiel des avions soit visible il faut à la fois la gestion des vols et la gestion de la mécanique

Nota bis : une discussion est ouverte sur les bargraphes

Pour faire simple, Joël utilise la symbolisation suivante : Bargraph.png

Blue.png potentiel consommé de 0 à 50

Green.png potentiel restant

Orange.png -10 à 0 : utilisation exceptionnelle

Red.png potentiel consommé de 0 à -10


En gardant la structure actuelle l’intégration au planning pourrait être faite sous la barre des créneaux

Planning_sous.png

ou sur le coté

Planning_cote.png

Calcul des potentiels restants

Le décompte des heures doit être réalisé à partir d'une base de référence. Celle-ci sera initialisée à chaque archivage de la base : heure totale à une date donnée.

Les heures sont stockées dans la base selon le principe retenu dans Time unit

Tous les calculs s’effectuent en cumulant les heures effectuées à partir de la date de référence pour l’avion. On s’affranchit ainsi des erreurs lorsque les visites sont effectuées en cours de journée

Les vols sont enregistrés dans la table Flight.

La requête demande dans la table Flight de calculer le total des temps de vol

 TOTTDV = count TIME where AIRCRAFT_NUM =$aircraft.


Pour le bargraphe il faut calculer le potentiel restant.

 INSP_TIME+ INTERVAL –REF_HRS-TOTTDV

Les couleurs des 3 rectangles sont proportionnelles aux heures trouvées.


présentation alternative

On peut aussi imaginer un bargraphe vertical, dont la hauteur serait décroissante proportionnellement au potentiel restant, et dont la couleur passerait du vert à l'orange puis au rouge. Bargraph_jdp.PNG --Jdepardieu 20:47, 5 December 2005 (CET)

évolution pour encombrement moindre

J'ai abandonné l'idée du bargraph sur la page d'accueil par manque de place. L'idée consiste à mettre un diode à gauche de l'immat de l'avion. Je vois la représentation comme cela :

  • Potentiel de 50 à 10 h = couleur verte
  • Potentiel de 0 à 10 h = couleur orangé
  • Potentiel - 5 à 0 h = couleur rouge
  • Potentiel < -5 h = couleur rouge clignotant
  • Date < 30 jours = couleur orangé
  • Date < 0 jours = couleur rouge
  • Date < -15 jours = couleur rouge clignotante

Pour compléter la chose un survol de la diode avec la souris afficherait un popup en java script avec la valeur du potentiel restant et de la date limite.

Il faut ajouter au formulaire des avions les champs pour renseigner les ref_date, ref_hrs, insp_date et insp_time. Le calcul du potentiel restant est :

  • Potentiel restant = insp_time - interval_visit - ref_hres

Ouverture du vol

Cette fonction doit être débrayable dans le menu club. En effet, certains clubs ne souhaiteront que la "fermeture du vol" : c'est-à-dire saisir au retour du vol toutes les infos concernant le vol.

L'utilité d'ouvrir le vol est de permettre aux personnes qui interrogent OF de savoir si un avion est parti ou non et d'avoir les détails du vol projeté.

Les paramètres déjà connus lors de la réservation s’affichent soit :

  • Le pilote
  • L’avion
  • L’instructeur
  • Le type de vol
  • La destination

Le pilote peut les modifier et il complète les informations suivantes :

  • Heure de retour prévue
  • Nombre de personnes à bord

(il faut une table pour stocker cela : peut-on utiliser la table flight en la laissant incomplète ?)

Après validation, le serveur vérifie la validité des qualifications, les documents avion (gestion mécanique) et indique :

  • Le potentiel restant (gestion mécanique)
  • Le nombre d’heures depuis le dernier plein (ou quantité d’essence ajoutée si différente du plein)

Dans le cas de la gestion du tableau de clé, lors du clic sur le bouton « Valider » le programme vérifie les conditions de validité avec ces paramètres puis il informe de son accord ou il autorise la prise de clé (option) puis ferme la fenêtre au bout de 30 secondes.

Affichage sur le planning résa que l’avion est parti.

Exemple de présentation :

Ouverture_vol.png

Fermeture du vol

Cette fonction doit être débrayable dans le menu club (sa présence ou non est liée à l'activation ou non de la gestion des vols). Si la fermeture du vol est débrayée l’ouverture l’est obligatoirement et les bargraphes ne sont pas applicables

Si l’ouverture est obligatoire le clique sur un vol en cours ouvre automatiquement la fenêtre de fermeture du vol

Si l’option ouverture est neutralisée, le clique sur une réservation une fois l’heure de début passée ouvre automatiquement la fenêtre de fermeture du vol.

->Si un pilote veut annuler sa résa après l'heure de début (c'est à dire, avec les règles de 1.2, en fait réduire la durée de la résa pour libérer l'avion) peut-il revenir sur la fenêtre de résa ?--Jdepardieu 17:39, 4 December 2005 (CET)

Sinon accès depuis menu

Les paramètres déjà connus lors de la réservation (ou l’ouverture du vol) s’affichent soit :

  • Le pilote
  • L’avion
  • L’instructeur
  • Le type de vol
  • Le terrain d’arrivée
  • Nombre de personne à bord

Il peut les modifier et il complète les informations suivantes :

  • Terrain de départ
  • Compteur d’arrivée
  • Compteur départ
  • Temps de vol
  • Heure de retour réelle
  • Nombre d’atterrissage
  • Avitaillement éventuel


Exemple de présentation :

Fermeture_vol.png

Lors de la validation il faut effectuer les vérifications avant stockage des valeurs dans la table Flight :

Pilote

dans cette fenêtre le pilote ne change plus mais lors d’un réaffichage pour modification ceci doit être envisageable. La vérification des qualifs n’a pas de sens à ce stade, même si c’est non valide il va falloir enregistrer les données

Instructeur

la validité des qualifs n’est pas à vérifier si on affiche dans la comboBox que les instructeurs qui ont une qualification valide

Nombre de passagers

sans vérification

Nombre d’atterrissage

volontairement l’initialisation peut être faite à zéro pour forcer les pilotes à effectuer la saisie. Toutefois ce choix induit beaucoup d’oubli et la page ne sera donc pas validée.

Type de vol

raisonnement identique aux atterrissages, l’initialisation par défaut à vol local risque de fausser les statistiques (les gens ont la flemme de modifier). Si on laisse par défaut sans option, la page ne sera pas validée

Terrain de départ et d’arrivée

pas de vérification

Temps de vol

les vérifications dépendent des options retenues au niveau club pour l’avion concerné


  • Si l’option « Calcul par horamètre » est activée, ce champ est neutralisé car l’heure se calcul à partir de la différence des compteurs.
  • Si l’option « Vérification du suivi des compteurs » est activée, celle ci empêche de mettre un temps de vol inférieur à la différence des compteurs (mais rien n’empêche de mettre plus).
  • Si l’option « Arrondir à 5 mn » est activée, et que la saisie ne respecte pas cette règle, affichage d’un message d’erreur.

Limiter la saisie à 9 h 59 pour un vol -- limite "en dur" ou limite paramétrable au noveau club ? --Jdepardieu 17:44, 4 December 2005 (CET)

Date et heure de fin de vol

date valide car issu de combobox. Il faut interdire la saisie de vol inférieure à la date de solde comptable. Si l’option « Arrondi à 5mm » (ou « Calcul par l’horamètre ») est activée, présentation des heures arrondies à 5 mn, sinon présentation de toutes les minutes.

a combobox que des avions activés dans le club donc pas de vérification

Compteur de départ

vérification de cohérence de la saisie par rapport au compteur du dernier vol. Il faut que le compteur soit supérieur au compteur du dernier vol. Si l’option tolérance est activée, (gestion des lectures de compteur différentes d’un pilote à un autre) il faut que le compteur soit inférieur au compteur d’arrivée précédente + tolérance. Sinon essayer de diviser par cent (oubli de la virgule) puis revérifier. Si toujours pas bon afficher message d’erreur en mentionnant le compteur précédent et demander la confirmation (2 fois). Si le compteur décalé est confirmé, enregistrer dans une table Forget_Flight les compteurs : arrivée précédente et départ actuel


Les vols sont enregistrés dans la table Forget_Flight (nouvelle table)

Compteur d’arrivée

vérification de cohérence de la saisie par rapport au compteur de départ., il faut que le compteur soit supérieur au compteur de départ et inférieur au compteur de départ +10 h. Sinon essayer de diviser par cent (oubli de la virgule) puis revérifier. Si toujours pas bon, afficher un message d’erreur et reboucler. Si le champ compteur est vide autoriser la sortie sans vérification (idem pour compteur de départ)

Avitaillement

si le nombre de litres est différent de 0 enregistrement des données dans une table

Les avitaillements sont à enregistrer dans la table Fuelling (nouvelle table)


S’il y a un règlement par le pilote le montant doit être enregistré dans la table Account, voir saisie des règlements

Exemple de présentation :

Reglement.png


Le montant du vol sera calculé en tenant compte des tarifs par avion et en fonction du type de vol


Ajout d'une nouvelle table aircraft_price

Il faut créer une table à plusieurs colonnes (avion, type de vol, prix) pour pouvoir y créer les tarifs que l'on souhaite.

Une discussion est en cours sur le sujet.

Le solde du compte sera calculé en additionnant les crédits et en soustrayant les débits depuis l’initialisation du compte du pilote. Ces champs sont ré-initialisés lors de l’archivage annuel (report à nouveau).


Vérifications avant validation

Modes de règlement :

Enfin, pour les types de réglement, là aussi, je suis favorable à une table qui permette de créer les types de paiement autorisés et d'y mettre des contraintes (qui a le droit de saisir ou non).--Christophe 10:44, 9 Jun 2005 (CEST)

  • Compte pilote : montant du vol déduit du solde du compte, si le montant est négatif affichage d’une fenêtre de rappel
  • Chèque : règlement par chèque, vérifier qu’il existe un montant différent de 0 dans le champs montant
  • Espèce : règlement par espèce, vérifier qu’il existe un montant différent de 0 dans le champs montant. Ce mode de règlement ne doit pas être possible sans que le membre, qui reçoit l’argent, valide en saisissant son login + mdp. Seul les personnes avec un profil trésorerie sont autorisées à encaisser les espèces
  • Carte de crédit : selon option club, module à développer dans une phase ultérieure si possible
  • Compte partagé : si un autre membre souhaite payer 50% du vol (les heures de vol ne seront pas comptabilisées à ce membre, seul un règlement est imputé)
  • Comptes tiers : paiement sur un autre compte. Les cas les plus courants sont les enfants sur le compte de la mère ou du père. C’est aussi le mode des règlements des vols baptêmes, vols initiation, convoyages (il faudra définir une règle de prise en charge au niveau club), mécaniques, etc…

En fonction du code saisi dans le champ compte tiers il faut vérifier si la personne à un profil l’autorisant à utiliser ce compte. Sinon il faut qu’un membre possédant cette autorisation valide la saisie du pilote (gestion à effectuer dans les profils)


Montant : vérifier la saisie d’un format correct


Compte tiers ou partagé : vérifier que le numéro de compte soit valide

Les données sont à enregistrer dans la table Account (nouvelle table)


Il faut enregistrer autant de lignes qu’il y a de comptes concernés

  • S’il y a un remboursement de carburant il faut l’enregistrer sur une ligne avec le numéro de ligne de la table Fuelling
  • S’il y a règlement il faut l’enregistrer sur une ligne avec le numéro de ligne de la table Flight, soit avec le compte pilote soit avec le compte tiers.


  • Si le compte est partagé il faut enregistrer une ligne pour le compte pilote et une autre au compte partagé.

Lors du rappel de ce vol pour modification il faut qu’il existe des liens permettant de rapatrier les éléments des différentes tables

Particularité de certains champs

ACCOUNT_NUM : réservé à la gestion de la base afin d’assurer la continuité des enregistrements avec l’auto incrément


FLIGHT_NUM : numéro de ligne de la table Flight pour relier le règlement à un vol


FUEL_NUM : numéro de ligne de la table Fuelling pour relier le règlement à un remboursement d’avitaillement

Je ne vois pas très bien pourquoi tu veux un champ par type de facture (essence, vol, etc.). Pourquoi ne pas mettre un seul champ qui contient un numéro lié à une table qui contient les types de factures possibles ?

Mais là, je n'ai aucune expérience. Il est vrai que cela me gêne de ne pas fixer en dure les "grands" types de paiement : vols, essences, double et divers. Mais peut-être peut-on avoir une position intermédiaire : un seul champ, pas relié à une autre table, mais contenant un code fixé par le logiciel en dure "E=essence, etc.". Je pense que l'avis des spécialistes des bases de données serait intéressant la-dessus.

--Christophe 10:45, 9 Jun 2005 (CEST)

VALID : Toutes les saisies en comptabilité sont soumises à la validation par le trésorier. Si la saisie d’une rentrée d’argent par le pilote est autorisée le montant sera validé par le trésorier lorsqu’il sera en possession de l’argent (0 ou 1)

Dés que l’on touche à l’argent les points de vue divergent, certains clubs n’admettront pas le principe de la libre saisie des sous. Pourtant cela fonctionne très bien avec ce mode de supervision. C’est le meilleur moyen de faire taire tous les pingres qui n’arrêtent pas de se plaindre que leurs comptes ne sont pas à jour. Dans les clubs sans secrétariat, une validation par semaine est suffisante. A la fin de chaque mois on fait un rapprochement bancaire et les montants non validés sont annulés. Comme ceci ne sera pas partagé par tous il faut une option de niveau club.


EXPORT : ce champ sera utilisé pour marquer les enregistrements exportés vers la comptabilité

Types de vols

La notion type de vol doit être comme pour le reste modulable. Elle nécessite donc l'utilisation de tables spécifiques définissant les types.

Une discussion est ouverte sur le sujet.

Au niveau de l'affichage des types de vol :

  • ne doivent être proposés que les types de vols compatibles avec l'avion conformément à la table flight_uncomp_aircraft
  • doivent être obligatoirement sélectionnés (et non modifiables(disable donc)) les types de vols obligatoires pour l'avion conformément à la table aircraft_mandatory_flight
  • doivent être vérifiés les types de vol nécessitant des qualifications. Cette vérification a lieu après validation, car elle doit intégrer la présence ou non d'un instructeur (s'il y a un instructeur alors la qualification n'est pas requise).

Exemple 1 : un club qui utilise à la fois des avions et des ulms. Certains aéronefs seront des avions et d'autres des planeurs. Il faudra donc forcer le type "ULM" ou le type "Avion" (si définis).

Exemple 2 : la case à cocher IFR n’apparaîtra que pour les avions IFR (aircraft_mandatory_flight) et si le pilote est qualifié IFR (flight_mandatory_qualification)

Exemple 3 : Le club définit les options voltige et vol de nuit, celles-ci seront présentes dans la boîte liste mais ont ne pourra pas choisir voltige de nuit (flight_uncomp_aircraft)

Favorite_icao

Pour les terrains de départ et destination, il faut prévoir une combo qui inclut :

  • les "favorite icao" (terrains les plus proches ou terrains les plus fréquentés) c'est à dire la liste de la table ci-dessous
  • les codes OACI et le nom en clair
  • proposer par défaut le nom du terrain de base
  • permettre de saisir un autre code oaci à la main (champ texte donc) (qui sera validé par la suite)

Pour ce faire, il faut créer une table : Favorite_Icao

Le remplissage de cette table doit se faire côté "flight-admin" et doit proposer les options suivantes :

  • nombre de terrains à inclure (de 5 à 99 par exemple)
  • type de moulinette permettant de choisir les terrains (les plus proches, ou les plus fréquentés)
  • permettre de supprimer à la main de la liste certains codes oaci et d'en rajouter d'autres

si la méthode retenue est "les plus fréquentés", alors les statistiques seront faites d'après la table des vols en comptabilisant les terrains d'arrivée.