Discussion:Flight Type : Différence entre versions

Version actuelle en date du 8 juin 2005 à 16:12

Pour moi la question des 2 tables "primitives" qui définissent le nom de chaque type de vol (table flight_type) et les incompatibilités entre eux (table uncomp_flight) est réglé.

Par contre, là où cela devient plus intéressant et plus épineux, concerne les "obligations de type de vol".

En effet, tant que la notion de type de vol est utilisée dans un but purement statistique, s'il y a des erreurs de "renseignement", ce n'est pas bien grave. On peut néanmoins limiter ce type d'erreur en rajoutant un champ par type d'avion permettant de sélecter des types de vol par défaut (ex: sur un CAP 10, sélectionner "voltige" par défaut).

Par contre, là où cela devient plus épineux, cela concerne les factures. En effet, si l'on édite une facture en fonction du type de vol, alors il faut que le type de vol soit bien renseigné. D'où 2 questions :

• as-t-on intérêt à éditer les factures en fonction du type de vol ?

• comment faire pour s'assurer que le type de vol est renseigné conformément à ce qu'il doit être ?

Pour la première question je répondrais "oui". En effet, le problème de la deuxième question persistera même si nous ne lions pas le test de conformité de la facturation au type de vol. Donc autant le lier au type de vol, en plus cela semble le plus naturel et le plus facilement définissable. Cela évite enfin d'avoir à créer une notion supplémentaire.

Pour s'assurer de la conformité du choix du type de vol, il y a en fait plusieurs aspects :

• on peut restreindre l'utilisation de certains types de vol à certaines personnes. Pour restreindre, plusieurs pistes :
  • rajouter dans la définition des profils, les types de vols utilisables. Exemple : un pilote lembda ne peut pas faire de vol de controle avion. Par contre, des pilotes qui auront le profil "baptême" pourront faire des... baptêmes.
  • on peut également lier les types de vols possibles aux qualifications détenues (ex : être qualifié IFR pour faire du vol aux instruments). Là aussi, on peut créer une qualification "baptême" et la lier à la possibilité de faire des baptêmes. (je préfère cette façon : c'est d'ailleurs ce qui est proposé avec la table flight_mandatory_qualification)

Mais pour le moment cela n'impacte que faiblement sur la facturation. Le gros soucis concerne, je pense, la double commande. En effet, si l'on ne force pas le type de vol "instruction" lorsque l'élève est avec un instructeur alors il va y avoir beaucoup d'"oublis".

Mais il ne me parait pas simple de lier la présence d'un instructeur dans l'avion avec le fait que le type de vol soit "instruction". Car le type de vol est défini de manière molle par l'administrateur du club. A contrario, le champ correspondant à l'instructeur dans une réservation, est en dure. Il en sera de même pour le carnet de route de l'avion.

Il faudrait donc imaginer un système qui permette de lier des éléments "dures" constatables par OF avec des éléments "virtuels" pour OF comme les types de vol.

Si l'on fait cela, on pourrait également envisager des obligations de type de vol, ou des propositions en présence de certains éléments ayant trait au vol.

Exemples :

- un vol de plus de 2 heures -> le proposer par défaut en navigation plutot qu'en vol local (sans contrainte pour autant)

- un vol avec des heures qui semblent correspondre à la nuit, le proposer en vol de nuit... (là aussi, il peut y avoir un impact dans le cas de paiement de balisage)

Concrêtement, la solution que je verrais, consisterait à créer en dure des identifications possibles (nuit, instructeur, etc.) et à permettre une liaison avec les types de vol existant. La difficulté consiste à proposer une "bibliothèque d'identifications d'états" suffisamment riche et surtout paramétrable...

Mais bon, c'est peut-être un peu trop ambitieux...

A l'époque Cogito avait répondu:

Je suis d'accord avec toi.
Je pense que la table TypeDeVol doit contenir un flag pour savoir si ce type nécessite la presence d'un instructeur (cas du double commande).
Il faut aussi un flag EQUIPAGE O/N pour les types de vol les supportant car ces heures doivent figurer dans le carnet de vol.

Aujourd'hui, je répondrais : oui, mais le problème doit surtout être pris à l'envers ! En effet, vérifier que si on coche "double-commande", il y a bien un instructeur à bord est une chose, mais vérifier que s'il y a bien un instructeur à bord implique que l'on coche double commande en est une autre. Et dans un soucis de s'approcher au plus près de la "véracité" du vol, je pense qu'il vaut mieux procéder selon la seconde possibilité : s'il y a un instructeur, alors on coche double commande automatiquement.

Il faut donc une table qui donne des obligations de cochage de champs, et éventuellement une table qui donne des propositions de cochage de champs.

--Christophe 17:12, 8 Jun 2005 (CEST)