Bien débuter avec OpenFlyers

Présentation

La solution OpenFlyers permet de gérer l'ensemble de l'activité d'une structure autour de 2 éléments principaux :

• La réservation
• La gestion de l'activité réalisée (c'est à dire la gestion des heures de vols dans le cadre d'une activité aéronautique)

La mise en place d'OpenFlyers au sein d'une structure peut se découper en 2 phases :

1. La mise en place de la réservation qui est relativement simple à appréhender
2. La mise en place de la gestion de l'activité qui nécessite un travail de fond pour bien définir les règles de gestion de la structure aussi bien en terme de politique de relation client qu'en terme de gestion comptable.

Recommandations sur les profils

Utilisateurs finaux

Chaque utilisateur doit disposer d'au moins un profil. Il est recommandé de limiter le nombre de profils par utilisateur à 1 dans la mesure du possible sauf pour des cas particuliers et notamment pour l'attribution de profils "transparents" pour les utilisateurs qui appartiennent à des groupements comme les Comités d’Établissements (C.E.) ou représentant une catégorie spécifique devant être identifiée comme telle (exemple : les formateurs). Cela améliore l'expérience de l'utilisateur qui n'a pas, dès lors, à choisir un profil à la connexion.

Dans la même optique de simplification, nous recommandons de rendre les profils "transparents" réellement transparents en leur cochant le droit "Profil non sélectionnable par l'utilisateur". Ainsi, l'utilisateur qui dispose de 2 profils (un sélectionnable et l'autre non sélectionnable), n'aura pas à choisir son profil à la connexion.

Accès à l'onglet Gestion

Les personnes disposant de profils ("Bureau", "Gestionnaire", etc.) permettant d'accéder à l'onglet Gestion doivent être en nombre limité. En général pas plus de 4 ou 5 personnes.

Si les tâches de gestion doivent être réparties entre plusieurs personnes alors il vaut mieux scinder les droits sur des profils spécifiques. Exemple : un profil "Trésorier" ou "Comptable" d'un côté et un profil "Secrétariat" de l'autre.

A l'inverse, attention à ne pas multiplier à l'infini le nombre de profils en créant un profil spécifique pour chaque utilisateur. Le logiciel n'est pas prévu pour cela et il sera rapidement impossible de créer de nouveaux profils. Aussi, le nombre de profils doit être défini à l'avance et ne devrait pas évoluer au cours du temps. Le droits affectés à chaque profil, peuvent eux évoluer au cours du temps.

Accès à l'onglet Admin

Il faut que le nombre de personnes ayant un profil "Admin", c'est à dire ayant accès à l'onglet Admin soit exactement compris entre 2 et 3 personnes, en plus des personnes de l'équipe OpenFlyers qui sont identifiables par leur nom suivi de "(OpenFlyers)".

En effet :

• Il ne faut jamais rester seul avec un profil "Admin". C'est une bonne pratique qui permet d'assurer la continuité de l'activité en cas de problème. C'est même une question de bonne gouvernance.
• Il n'y a pas de raison d'avoir plus de 2 ou 3 personnes à disposer des droits pour intervenir sur le paramétrage d'une plateforme. Cela permet de limiter les risques de déstabilisation du paramétrage. Les risques induits à cette déstabilisation sont les coûts de restauration voir de perte de données.

OpenFlyers dégage sa responsabilité à chaque fois qu'un administrateur d'une structure effectue une action depuis l'onglet Admin.

Mettre en place la réservation

La mise en place de la réservation nécessite de définir uniquement :

• Les profils et droits associés pour les utilisateurs
• Les règles concernant les réservations
• Les ressources (les aéronefs dans le cas d'une activité aéronautique)
• Éventuellement les validités afin de générer des alertes pour les utilisateurs à la connexion et/ou à la réservation

Le paramétrage et la mise en production de cette phase peut être très rapide et ne nécessite pas de date clé comme pour la mise en place de la gestion d'activité.

L'import de données externe est également limité à importer uniquement le fichier des utilisateurs. Cependant, plus ce fichier sera complet au moment de l'import et moins de reprises manuelles seront nécessaires. Ainsi, des données comme l'adresse, la date de naissance ou le sexe de chaque utilisateur peuvent être incluses dans le fichier d'import.

Les risques associés à la mise en production des réservations est quasiment nul car il n'y a aucun mouvement comptable de généré et il n'y a pas d'export à effectuer par la suite : les réservations tournent en vase clos.

La mise en place des réservations peut être effectuée indifféremment par l'équipe OpenFlyers dans le cadre du forfait paramétrage ou par un administrateur au sein de la structure cliente.

Sécuriser les réservations

La mise en place des réservations par internet apporte une plus grande facilité pour les utilisateurs : ils peuvent plus facilement réserver. La contre-partie de cela est qu'ils peuvent aussi plus facilement annuler leurs réservations, notamment à la dernière minute. Ainsi, la souplesse peut apporter de l'instabilité.

Pour faire face à cela, OpenFlyers proposent différentes solutions ou recommandations en fonction de la population des utilisateurs et de l'activité. Il est important de garder à l'esprit que les contraintes qui peuvent être mises en place doivent être proportionnées par rapport aux problèmes rencontrés.

Ainsi, dans les petites structures, ou les personnes se connaissent plus facilement, il vaut mieux éviter les règles ou contraintes trop drastiques qui risquent d'en refroidir plus d'un et leur privilégier une communication adaptée.

Voici une liste "croissante" des solutions qui peuvent être mises en place :

• Prévoir dans le contrat, les conditions d'utilisations ou le règlement intérieur les règles en cas d'annulation tardive en définissant ce qu'est une annulation tardive (par exemple moins de 24 heures avant). Ces règles peuvent prévoir une facturation spécifique et les conditions de "déclenchement" de cette facturation. Ainsi, une règle qui n'est pas appliquée systématiquement mais plus au cas par cas, passera mieux.
• Limiter le nombre de réservations par personne afin d'éviter que des "petits malins" ne "trustent" les disponibilités pour les annuler au dernier moment.
• Mettre en place le surbooking pour permettre à d'autres utilisateurs de se mettre en attente sur un créneau pour une ressource donnée et ainsi de récupérer automatiquement des créneaux qui se libéreraient au dernier moment.
• Permettre aux utilisateurs d'être notifiés par email en cas d'annulation.
• Facturer automatiquement et systématiquement les réservations existantes à J-X où X est fonction de la structure.

Mettre en place la gestion d'activité sur OpenFlyers

La mise en place de la gestion d'activité sur OpenFlyers se fait à n'importe quel moment de l'année. Le passage en production se fait idéalement au 1er janvier pour bénéficier du changement d'exercice comptable et de la clôture de l'exercice précédent pour récupérer les à nouveaux des comptes, notamment ceux des comptes clients.

La mise en place de la gestion d'activité doit être bien préparée. Car une fois en production, les données qui seront saisies généreront des écritures comptables qui seront éventuellement exportées vers un logiciel de comptabilité. Un mauvais paramétrage ou une mauvaise définition des besoins peut engendrer des erreurs latentes qui n'apparaitront pour certaines qu'à la fin du 1er exercice comptable si aucune vérification n'est effectuée d'ici là. Il sera alors difficile d'en retrouver l'origine et la correction des mauvaises écritures sera une tâche laborieuse et fastidieuse.

C'est la raison pour laquelle nous avons défini un ordre chronologique des actions à effectuer afin de limiter tout risque d'erreur.

Les risques associés à la mise en place de la gestion d'activité restent également limités : OpenFlyers n'effectue aucune opération sur des comptes bancaires réels. Par conséquent toute erreur d'écriture comptable peut être corrigée à n'importe quel moment par une contre-écriture. Le point le plus critique que nous avons identifié concerne pour l'aéronautique le décompte des heures de vols par OpenFlyers qui permet de déterminer les visites de maintenance. De ce fait, il est important de bien tester et valider le mode de calcul et de décompte. Le logiciel en lui-même est largement éprouvé puisqu'il approche les 300.000 vols saisis en 5 ans sans aucun problème.

La chronologie pour la mise en place de la gestion d'activité est présentée dans les paragraphes qui suivent.

Définir le périmètre comptable géré par OpenFlyers

OpenFlyers peut être utilisé de 3 façons différentes pour la gestion comptable.

Gestion du chiffre d'affaire dans OpenFlyers

La saisie de l'activité, et donc la génération du chiffre d'affaire au travers des factures clients et des écritures comptables, se fait dans OpenFlyers.

Les comptes clients sont gérés par OpenFlyers.

Gestion des charges dans OpenFlyers

En plus de la gestion du chiffre d'affaire dans OpenFlyers, dans ce cas, les factures fournisseurs sont également saisies dans OpenFlyers. L'ensemble des écritures courantes, c'est à dire celles qui impactent le compte d'exploitation, sont saisies dans OpenFlyers.

Cela implique que les comptes de tiers sont à jour dans OpenFlyers.

Gestion comptable complète dans OpenFlyers

En plus de la gestion du chiffre d'affaire et de la gestion des charges dans OpenFlyers, les écritures du bilan sont également saisies dans OpenFlyers.

Cela implique que l'intégralité du plan comptable de la structure soit à jour dans OpenFlyers.

Impact sur les exports

A noter que quelque soit le périmètre choisi, OpenFlyers pourra générer l'export comptable vers le logiciel comptable utilisé pour saisir les "autres" écritures. Il faut donc bien avoir conscience que la bonne et unique façon de fonctionner est la suivante :

• Ce qui doit être saisi dans OpenFlyers n'est saisi que dans OpenFlyers
• Ce qui doit être saisi dans OpenFlyers est saisi avant tout export
• On n'importe jamais dans OpenFlyers des données saisies dans un logiciel de comptabilité

Cela peut se résumer au principe d'hygiène de "la marche en avant" appliqué dans les cuisines pour les aliments : les données ne doivent jamais rebrousser chemin et ne doivent jamais se croiser.

Paramétrer la plateforme

Nous recommandons vivement de déléguer cette opération à l'équipe OpenFlyers au travers du forfait paramétrage. Les avantages sont les suivants :

• Vous gagnez du temps
• Vous tirez profit d'un paramétrage adapté à votre structure grâce à notre connaissance de votre métier
• Vous tirez profit de la puissance de la solution OpenFlyers grâce à notre maitrise de ses fonctionnalités

Si vous souhaitez effectuer vous-même ce paramétrage, alors vous devez avoir reçu au préalable une formation par la SARL OpenFlyers. Cette formation est indispensable afin d'avoir la garantie que le paramétrage que vous mettrez en œuvre sera fait dans l'esprit du logiciel OpenFlyers. Cela garantie la pérennité de votre paramétrage lors des mises à jour d'OpenFlyers.

Forfait paramétrage

Nous proposons un forfait paramétrage qui s'appuie sur un questionnaire détaillé complété par la structure cliente. Ce questionnaire est sous la forme d'un fichier tableur communiqué sous 2 formats (Excel et OpenOffice).

Ce forfait paramétrage inclut toute la configuration d'OpenFlyers :

• Mise en place des ressources ;
• Création des profils utilisateurs ;
• Paramétrage du décompte du temps vol ;
• Mise en place de la comptabilité :
  • Module de vente des produits ;
  • Moteur de création des écritures comptables associées aux ventes (heures de vols, produits) ;
• Définition des validités (licences, qualifications, échéances administratives, légales, médicales, etc.) ;
• Mise en place des rapports types parmi ceux publiés.

Nous attirons votre attention sur le moteur de création des écritures comptables qui permet d'automatiser toutes les écritures comptables qui doivent être générées lors d'une vente de produit. Grâce à sa puissance, nous mettons en place la ventilation automatique des facturations de groupement de clients comme les comités d'entreprises par exemple ou l'application de remises pour des catégories de clients.

Le forfait paramétrage inclut également l'import des utilisateurs par le biais d'un fichier informatique au format OpenOffice ou Excel que nous vous communiquons et que vous nous retournez rempli. Il est possible de personnaliser cet import en reprenant tout ou partie, selon la compatibilité des champs, des extractions en provenance d'un autre logiciel de gestion. Dans ce cas, l'import des champs additionnels nécessite un travail supplémentaire, hors forfait paramétrage, qui est déduit des heures de bonus assistance/développement.

Vous pouvez retrouver le tarif du forfait paramétrage dans notre catalogue tarifaire si vous êtes en abonnement "First Price". Pour les abonnements supérieurs, le forfait paramétrage est inclus.

Chronologie du forfait paramétrage

La procédure pour profiter du forfait paramétrage est la suivante :

1. • Dans le cas où vous disposiez déjà d'un abonnement à une ancienne version 1.3 ou 2.1 d'OpenFlyers, vous devez d'abord nous demander de migrer votre plateforme sous version 3
   • Dans le cas où vous disposiez pas déjà d'une plateforme OpenFlyers, il vous faut d'abord la créer.
   • Dans le cas où vous disposiez d'une plateforme OpenFlyers sous version à jour, il n'y a pas d'étape 1.
2. Dans tous les cas, vous créez les factures correspondantes le cas échéant (selon votre abonnement) puis vous les payez.
3. Une fois que les factures générées sont acquittées (cela peut être immédiat en payant par carte bancaire) vous nous envoyez un e-mail pour nous en informer et on vous transmet par retour d'e-mail un questionnaire. Parallèlement à cela, si vous êtes en version 1.3 ou 2.1 nous programmons avec vous une mise à jour de votre plateforme.
4. Vous nous retournez le questionnaire paramétrage rempli.
5. Nous parcourons le questionnaire pour vérifier qu'il est complet. Si ce n'est pas le cas, nous vous demandons des précisions.
6. Une fois que le questionnaire est retourné complet et que votre plateforme est sous version 4, nous nous engageons à mettre en place le paramétrage initial sous 15 jours hors période du 21 décembre au 5 janvier. Ainsi, si la période de paramétrage comprend une partie de cette période, alors la date limite de mise en place du paramétrage est reportée de 15 jours. Exemple : une date limite initiale qui tombe le 26/12 sera reportée au 10/01.
7. Ce paramétrage sera suivi par une validation par vos soins (en général des ajustements sont nécessaires). Nous vous enverrons un e-mail vous demandant de bien vouloir nous confirmer que le paramétrage effectué correspond à vos attentes. A défaut de réponse dans un délai de 1 mois, nous considérerons que le paramétrage effectué est bon.
8. Une fois que vous aurez terminé la validation du paramétrage, nous pourrons procéder, à votre demande et sans frais supplémentaire, à une suppression complète des écritures comptables et d'activités qui auront été saisies pour tester le paramétrage. Ce nettoyage peut être étendu aux réservations et/ou aux validités.
9. Enfin, postérieurement au passage en production, nous vous enverrons, sur votre demande, un fichier .csv contenant la liste des utilisateurs pour que vous puissiez nous le retourner complété des soldes de compte afin que nous procédions à l'import des à nouveaux des comptes clients. C'est aussi après le passage en production que vous pourrez initialiser les compteurs et potentiels des aéronefs.

Tester la configuration

Avant de passer en production, il faut vérifier qu'il n'y a pas de "grosses erreurs". Ces tests doivent se porter essentiellement sur les actions suivantes :

• Création d'utilisateurs
• Vérification que les comptes associés aux utilisateurs sont automatiquement créés
• Saisie des écritures types de l'activité

Dans le cas d'une activité aéronautique, cette saisie consiste à saisir des vols

• Vérification que les factures générées sont conformes à ce que l'on attend.

En cas d'écart constaté, il faut nous remonter les anomalies par e-mail de façon la plus précise possible en suivant le guide de rapport d'anomalie de paramétrage.

Il est déconseillé d'utiliser le profil "Admin" pendant la période de test du paramétrage afin d'être certain de ne pas modifier ce qui a été configuré. Sans quoi, l'équipe OpenFlyers n'assure pas le support sur le travail réalisé. Il est néanmoins possible de se connecter avec le profil "Admin" pour "jeter un œil" sur le paramétrage.

Une fois en production, le gestionnaire à toute latitude pour ne garder que le profil "Admin". Néanmoins, là encore, il est déconseillé d'effectuer des modifications du paramétrage sans en maitriser les conséquences. Il vaut mieux demander à l'équipe OpenFlyers d'intervenir, notamment dans le cadre des heures d'assistance ou réaliser des tests sur une plateforme "sandbox".

Nettoyer la base de données avant le passage en production

Cette opération est effectuée par l'équipe OpenFlyers dans le cadre du forfait paramétrage. Elle consiste à supprimer toutes les écritures comptables, toutes les écritures d'activités (vols dans le cas d'une structure aéronautique) créées durant les tests de validation du paramétrage.

De plus, il est également possible de réinitialiser les validités. Cela consiste à supprimer toutes les validités détenues par les utilisateurs. Cette opération n'est faisable que lorsqu'il s'agit d'une nouvelle plateforme qui n'était donc pas déjà en production sur la gestion des validités. De même, cette réinitialisation ne peut être effectuée si lors de l'import des utilisateurs, il a été procédé à l'import additionnel de validités.

Enfin, si la structure n'était pas en production sur les réservations et que seules des réservations fictives ont été saisies, alors il est possible de réinitialiser également toutes les réservations.

Une fois ce nettoyage effectué, la structure est considérée comme en production et nous n'intervenons plus directement sur la base de données pour y modifier ou supprimer des écritures comptables. Ce principe permet de garantir la confiance entre les parties prenantes.

Ce nettoyage doit être anticipé de plusieurs jours avant la date de mise en production théorique afin de laisser le temps à l'équipe OpenFlyers d'effectuer cette opération avec sérénité. Dans le cas où le passage en production réel est programmé pour le 1er janvier, alors il est recommandé de demander la réinitialisation de la base de données au moins une semaine avant la période des vacances de noël. En effet, pendant la période des vacances de Noël nous effectuons un embargo sur les réinitialisations de base de données car nous travaillons en effectif réduit et gardons un maximum de disponibilité pour assurer le suivi des clients en production. De plus, les jours fériés venant s'ajouter aux week-ends il est difficile de trouver des jours qui ne soient pas la veille d'un jour férié ou d'un week-end. Enfin, par expérience, toute réinitialisation effectuée sous la pression engendre des problèmes dues à des erreurs de traitement. Par conséquent, il vaut mieux retarder cette opération pour pouvoir l'effectuer sereinement plutôt que de générer des problèmes et des inquiétudes alors que les disponibilités et la concentration de chacun sont réduites du fait des fêtes de fin d'année.

Passer en production

Le passage en production doit se faire à une date donnée et définie à l'avance, par exemple un 1er janvier. Cependant :

• Le 1er janvier personne ne travaille chez OpenFlyers et en général dans les structures clientes d'OpenFlyers. Il s'agit donc d'une date théorique.
• Le passage en production côté OpenFlyers est considéré à partir du moment où la réinitialisation de la base de données a été faite. Cela peut remonter à plusieurs semaines à l'avance et il est recommandé d'anticiper cette phase.
• Le passage en production côté structure peut avoir lieu en pratique que le 2, 3 ou 4 janvier pour une mise en production au 1er janvier. Les écritures comptables et d'activités seront saisies rétroactivement.

Comptablement, cela suppose :

• Qu'avant cette date théorique, toutes les écritures ont été saisies dans l'ancien système de gestion utilisé
• A partir de cette date théorique, toutes les écritures seront saisies dans OpenFlyers

Il est primordiale de bien comprendre que les écritures comptables ne doivent être saisies que dans un seul système.

Attention : A la date réelle du passage en production (par exemple 3 jours après la date théorique), il n'est pas encore possible d'exporter les soldes des comptes clients de l'ancien système de gestion car les écritures de l'exercice précédent n'ont pas encore été consolidées. Aussi, nous recommandons fortement de ne pas se précipiter pour rapatrier les soldes des comptes clients et de procéder en 2 temps :

1. Passer en production sur la saisie des vols à la date convenue avec des à nouveaux de comptes clients à 0 (donc faux).
2. Rapatrier ultérieurement les à nouveaux correspondant à la date de début d'exercice. Les à nouveaux s'inséreront dans les relevés de compte en début d'exercice correctement et les soldes des comptes clients deviendront alors juste.

Le passage en production ne nécessite aucune action particulière si ce n'est de donner les droits de saisie aux utilisateurs concernés.

Pour l'activité aéronautique :

• les premières saisies d'heures de vols mettront automatiquement à jour les compteurs des aéronefs.
• les validités avec expérience récente (par exemple "un vol tous les 3 mois") ne devront être paramétrés comme bloquant que lorsque le passage en production sera effectif depuis une durée supérieure à la période de calcul des validités avec expérience récente (par exemple 3 mois dans l'exemple donné).

Dans tous les cas, tant que les à nouveaux des comptes clients n'auront pas été rapatriés, le calcul du solde de leur compte sera faux. Il ne faut donc pas activer les blocages pour les soldes insuffisants, si cela est prévu, tant que les à nouveaux ne seront pas mis à jour.

Enfin, si la date de passage en production est prévue pour un 1er janvier, pensez au fait que votre structure n'est pas la seule dans ce cas. C'est la raison pour laquelle il faut prévoir un délai côté OpenFlyers pour la réinitialisation, un délai dans l'import des à nouveaux après cette date et également un délai dans le traitement des demandes de dernière minute.

Rapatrier les à nouveaux des comptes de bilan

Le rapatriement des à nouveaux des comptes de bilan doit être effectué uniquement lorsque la comptabilité de l'exercice précédent a été consolidée et validée dans l'ancien système de gestion de la comptabilité.

Cette opération s'effectue donc forcément après le passage en production de la comptabilité dans OpenFlyers et peut nécessiter plusieurs semaines dans le cas de consolidation ou de vérifications nécessitant du temps sur l'ancien système.

L'étendu des soldes de comptes à importer diffère suivant le périmètre de gestion dans OpenFlyers retenu par la structure :

1. Dans le cas où OpenFlyers gère seulement le chiffre d'affaire, il faut importer uniquement les à nouveaux des comptes clients
2. Dans le cas où OpenFlyers gère en plus les charges, il faut importer également les à nouveaux des comptes fournisseurs et des comptes financiers
3. Dans le cas où OpenFlyers gère toute la comptabilité, il faut importer l'intégralité des comptes du bilan

Dans les cas 2 et 3, l'import des comptes de bilan qui ne sont pas des comptes clients, doit s'effectuer manuellement en saisissant des flux qui débitent ou créditent le compte de bilan à initialiser et dont la contre-partie va sur le compte Report à nouveau. Voir la procédure Initialiser le solde d'un compte de bilan.

Dans le 3ème cas, les comptes du bilan qui ne correspondent pas aux clients, fournisseurs ou aux comptes financier peuvent être importés bien après le passage en production de la comptabilité dans OpenFlyers. En effet, il n'y a besoin d'effectuer des contrôles réguliers que sur les comptes financiers et les comptes de tiers.

Lorsque l'intégralité de la comptabilité est mise en place dans OpenFlyers et que l'intégralité des comptes de bilan est initialisé, alors le compte de contre-partie se retrouve à 0 du fait de l'équilibre général de la comptabilité en partie double.

Rapatrier les à nouveaux des comptes clients

La meilleure méthode pour initialiser le solde des comptes clients est d'importer un fichier csv contenant le solde de chaque compte client avec les références du client.

Dans le cadre du forfait paramétrage, nous recommandons de confier cette opération à l'équipe OpenFlyers. Nous vous communiquerons un fichier préformaté au format csv. Il vous faudra juste nous le retourner en ayant renseigné les soldes des comptes clients et en nous indiquant la date comptable retenue pour l'import.

Le rapatriement des à nouveaux s'effectue conformément à la pratique comptable : il s'agit d'une écriture qui vient débiter ou créditer le compte de l'utilisateur concerné à une date comptable choisie et dont la contre-partie va sur le compte de report à nouveau.

Voici un exemple :

• La structure passe en production au 1er mai. A cette date, l'import n'est pas effectué. Les soldes de tous les comptes sont à 0 car aucune écriture comptable n'a encore été enregistrée.
• Un utilisateur X effectue une activité le 3 mai qui génère une facture client et donc un débit sur son compte de 200 €.

Ainsi, le compte de l'utilisateur X au 3 mai se présente ainsi :

Date	Intitulé	Débit	Crédit
01/05/xx	Solde du compte	000.00 €	000.00 €
03/05/xx	Activité	200.00 €	000.00 €
31/05/xx	Solde du compte	200.00 €	000.00 €

• L'import des à nouveaux s'effectue réellement le 15 mai à la date comptable du 1er mai. Dans la comptabilité précédente, l'utilisateur X présentait au 30 avril un solde positif de 300 €. L'import va donc générer une écriture au crédit sur son compte de 300 € à la date du 1er mai. Après import des à nouveaux, le compte de l'utilisateur X se présentera ainsi :

Date	Intitulé	Débit	Crédit
01/05/xx	Solde du compte	000.00 €	000.00 €
01/05/xx	Import à nouveau	000.00 €	300.00 €
03/05/xx	Activité	200.00 €	000.00 €
31/05/xx	Solde du compte	000.00 €	100.00 €

Mettre en place un workflow adapté à OpenFlyers

Une fois en production, OpenFlyers recommande de mettre en place un workflow adapté au logiciel afin d'en faciliter l'usage et de respecter les bonnes pratiques en terme de suivi d'activité.

Terminal de paiement électronique virtuel

Principe de fonctionnement du couplage entre OpenFlyers et un TPE virtuel

Lorsque une plateforme OpenFlyers est couplée à un terminal de paiement par internet fourni par une banque voici la chronologie de son utilisation :

1. Un utilisateur autorisé, se connecte à OpenFlyers.
2. Il va sur la page OpenFlyers lui permettant de saisir un encaissement.
3. Il sélectionne le type de paiement "carte bancaire en ligne" (l'intitulé est modifiable pour chaque plateforme)
4. Il saisit le montant qu'il souhaite verser sur son compte client.
5. Il valide le formulaire de saisie de l'approvisionnement et se retrouve dirigé sur l'interface du terminal de paiement électronique de la banque
6. Là, il saisit ses coordonnées bancaires : elles ne sont donc pas transmises à OpenFlyers
7. Si la transaction est acceptée par la banque, le serveur OpenFlyers hébergeant la plateforme est automatiquement informé
8. Le compte de l'utilisateur est crédité du montant correspondant et la contre-partie va sur le compte de trésorerie correspondant à ce mode de paiement. Cette écriture est automatiquement validée car elle a été sécurisée.

Il n'y a donc rien à faire côté gestion. Sur le compte de trésorerie, le mouvement apparait comme pour les autres mouvements qui correspondent à des encaissements :

• Dans la colonne Compte affecté est indiqué le nom du compte de contre-partie, c'est à dire le compte de l'utilisateur avec son nom et prénom.
• Dans la colonne Commentaire apparait le type de paiement, par exemple "carte bancaire en ligne".

Les avantages d'un TPE virtuel sur un TPE physique sont les suivants :

• Un utilisateur peut approvisionner son compte depuis n'importe où, à partir du moment où il a une connexion internet. Avec un TPE physique il est obligé de se déplacer là où il y a le TPE pour effectuer son approvisionnement. Le TPE virtuel permet de rendre acceptable des restrictions liées au solde du compte. Ainsi, il est tout à fait acceptable pour un utilisateur de se retrouver bloqué pour pouvoir réserver par manque d'argent sur son solde si parallèlement il a la possibilité d'approvisionner son solde.
• Cela supprime une tâche de pointage pour le gestionnaire.

Les inconvénients d'un TPE virtuel sur un TPE physique sont les suivants :

• Il y a un surcoût d'abonnement côté OpenFlyers de 120 € HT/an sauf dans le cas de l'abonnement Business+ où il est inclus dans l'abonnement.

Il n'y a pas de différence entre un TPE virtuel et un TPE physique pour les éléments suivants :

• Les coûts bancaires : ils sont normalement identiques par rapport à un TPE physique.
• Les paiements extérieurs : il est possible pour les clients concernés de saisir directement leur numéro de carte bancaire dans le TPE virtuel. Il faut simplement qu'un gestionnaire se connecte à OpenFlyers et ensuite affiche l'interface de saisie des encaissements en précisant "non-utilisateur" puis le nom du client OpenFlyers, qui peut être générique et le montant. Après redirection vers le TPE virtuel, il faut laisser le client saisir le numéor de sa carte bancaire avec les éléments associés.

Sécurité des données bancaires et double authentification 3-D secure

OpenFlyers ne reçoit, et à fortiori, ne stocke aucune donnée bancaire. Par donnée bancaire, il faut entendre les éléments liés à la carte bancaire d'un utilisateur. En effet, chaque utilisateur qui effectue un paiement par carte bancaire en ligne depuis OpenFlyers, est redirigé sur le TPE de la banque de la structure. Les données bancaires sont donc stockées auprès de la solution TPE souscrite auprès de la banque par la structure. Cela permet de garantir le niveau le plus élevé de sécurisation des transactions.

Chaque banque propose ou impose une double authentification dite 3-D secure. Il s'agit du fait que l'utilisateur qui insère les éléments de sa carte bancaire devra ensuite confirmer qu'il s'agit bien de lui en renseignant un code reçu par exemple par SMS.

La double authentification a pour objectif d'empêcher une utilisation frauduleuse des éléments d'une carte bancaire qui auraient été dérobés. Cela protège le vendeur contre le risque de livrer un produit pour lequel il aurait à faire face à un impayé. En effet, si le propriétaire de la carte bancaire fait opposition, l'argent que devait recevoir le vendeur peut lui être retiré. Si le produit est déjà livré, c'est trop tard.

Dans le cadre des structures aéronautiques, le risque d'impayé lié à un vol de carte bancaire est très faible. En effet :

• le produit fourni est immatériel (il s'agit en général d'effectuer des heures de vol) et la livraison est décalée dans le temps. De ce fait, la probabilité pour un voleur d'obtenir la livraison des heures de vols avant qu'il y ait une opposition est très faible
• le cercle des clients est souvent fermé (les membres d'une structure par exemple) et ils sont rencontrés physiquement. Là encore, il serait présomptueux pour un voleur d'utiliser une carte bancaire dérobée pour payer ses heures de vols.

Néanmoins, la double authentification a un aspect psychologique : elle peut rassurer certains utilisateurs finaux qui auront le sentiment d'être dans un environnement rassurant si lorsqu'ils font un paiement par carte bancaire, ils doivent confirmer ses éléments insérés par l'utilisation d'un code de confirmation.

A l'inverse, elle peut freiner certains utilisateurs qui ne sauront pas récupérer l'élément de confirmation ou ne comprendront pas ce qu'ils doivent renseigner.

Il appartient donc à chaque structure, si sa solution TPE qui lui est proposée lui permet de choisir ou non l'activation de 3-D secure, de peser les avantages et inconvénients. Voir la page Wikipedia 3-D secure pour plus de renseignements.

Mettre en place un TPE virtuel

A noter qu'il faut être sous la version 4 ou supérieure d'OpenFlyers.

Voici comment procéder pour créer un TPE virtuel (Terminal de Paiement Electronique en ligne) :

1. Contacter votre banque pour :
   • connaitre le module de paiement qu'elle propose et nous l'indiquer afin de vérifier qu'OpenFlyers est bien compatible. Il faut aussi nous indiquer le nom de la banque.
   • obtenir son accord de principe sur la mise en place d'un TPE virtuel (normalement cela ne devrait pas poser de problème)
2. Nous envoyer un e-mail en nous indiquant le système utilisé par votre banque. Trois cas peuvent se présenter :
   • nous avons déjà fait un interfaçage avec la solution utilisée par votre banque. Dans ce cas, la mise en place peut être très rapide.
   • nous n'avons pas encore fait d'interfaçage mais plusieurs clients d'OF sont intéressés et nous sommes en mesure de le réaliser pour un coût raisonnable. Dans ce cas, le délai peut être de quelques mois ou plus rapide si vous prenez en charge le coût de réalisation.
   • nous n'avons pas fait d'interfaçage et cette solution est très spécifique. Dans ce cas, nous ne ferons un interfaçage que si vous acceptez de supporter les coûts de développement.
3. Une fois que nous vous avons répondu positivement, il vous appartient de nous confirmer votre demande de mise en place
4. Souscrire à la version 4 ou supérieure d'OpenFlyers si la plateforme est sous une version antérieure.
5. Nous éditons la facture correspondant aux frais de maintenance annuels (voir notre catalogue tarifaire) et nous vous communiquons les informations nécessaires à votre banque qui dépendent du système utilisé par la banque. Voici les informations génériques pour toutes les banques :
   • Nom du commerçant ou raison sociale du commerçant : mettre le nom de votre structure
   • Nom de la boutique, du site de e-commerce, intitulé de l'enseigne commerciale : mettre le nom de votre structure
   • Type de site web marchand : indiquer qu'il s'agit d'une solution générique développée l'éditeur logiciel OpenFlyers
   • Nom du client ou nom du propriétaire du TPE : mettre le nom de votre structure
   • Nom du représentant : mettre le nom d'une personne agissant en qualité de représentant de la structure
   • Adresse email du représentant : Attention pour l'adresse qui recevra le couple identifiant/mot de passe d'accès à la gestion du TPE mettre impérativement une adresse email pérenne de la structure et surtout pas une adresse email OpenFlyers.
   • Adresse du site internet, adresse du site marchand : il s'agit de l'adresse de votre plateforme OpenFlyers par exemple https://openflyers.com/demo-fr/
   • Éditeur du site internet, nom de l'hébergeur : S.A.R.L. OPENFLYERS. Les mentions légales (adresse, numéro SIRET, etc.) figurent sur nos factures.
   • Nom et prénom de la personne en charge du site ou interlocuteur technique : Indiquer le nom de votre contact OpenFlyers.
   • Adresse de l'hébergeur : mettre l'adresse courrier d'OpenFlyers indiqué sur nos factures.
   • Adresse e-mail de l'hébergeur : mettre l'adresse e-mail de votre interlocuteur chez OpenFlyers.
   • Numéro de téléphone de l'hébergeur : laisser vide ou mettre le numéro 0892.494.123.
   • Système d'exploitation : Linux 64 bits
   • Environnement de développement : PHP
   • Interlocuteur technique : Mettre le nom de votre interlocuteur chez OpenFlyers.
   • Interlocuteur Administratif ou administrateur web pour l'accès au back-office : il s'agit du back-office de la banque. Il faut indiquer le nom de la personne dans votre structure qui sera en charge d'aller consulter. En général il s'agit de la même personne que celle qui fait office d'administrateur OpenFlyers. Cela peut être aussi une personne en charge de la comptabilité. Mais dans ce cas, il faut qu'elle est aussi des notions en informatique.

   Attention : dans le cas d'un TPE SIPS ATOS il faut préciser dans le formulaire que l'exécutable devant contenir la clé de décryptage doit être compilée pour Windows 64 bits.

6. Vous payez la facture
7. Vous nous communiquez les éléments de votre banque nous permettant de raccorder OpenFlyers à votre TPE virtuel en suivant la procédure TPE correspondante à votre type de TPE.

   Attention : dans le cas où la banque vous fait parvenir par courrier des documents, conservez-les. Ne transmettez à OpenFlyers que les certificats finaux que vous aurez récupéré directement soit depuis une interface web de la banque soit depuis un programme à installer sur le PC.

8. Nous effectuons le raccordement
9. Nous testons et quand c'est positif nous vous envoyons un e-mail. Charge à vous, lorsque c'est demandé par votre banque, de renseigner le PV de test.

Notre prestation ne prévoit pas d'intervention auprès de la banque et nous ne pouvons agir en tant qu'intermédiaire. En effet, la mise du TPE nécessite de la part de la structure la souscription d'un contrat auprès de sa banque : nous ne pouvons signer les papiers contractuels à la place de la structure ni s'engager en son nom. De plus, il est indispensable que la structure soit destinatrice de l'ensemble des documents envoyés par la banque et qu'ensuite elle nous remette uniquement ce qui nous est nécessaire et que nous demandons en fonction du TPE à mettre en place.

Certaines banques vérifient la présence des mentions légales lors de la demande de mise en place du TPE. Ces mentions légales doivent être présentes sur le site vitrine de la structure. La plateforme OpenFlyers doit être considérée comme une sous-partie privative de ce site et n'a donc pas vocation à accueillir les mentions légales.

TPE virtuel et test

S'assurer avant de procéder à des tests avec le TPE, que les utilisateurs disposent d'une adresse email valide.

Liste des modules de paiement reconnus par OpenFlyers

OpenFlyers a développé des interfaçages avec les modules de paiement des différentes banques françaises.

4 points d'attention :

• Pour certaines banques, il existe plusieurs modules de paiement possibles : cela peut dépendre de la région géographique ou d'une évolution au niveau de la banque qui lui fait abandonner un ancien système au profit d'un plus récent.
• OpenFlyers s'interface UNIQUEMENT avec les modules de paiement des banques et en aucun cas directement avec les modules de paiement qui peuvent être proposés par des sociétés tierces spécialisées dans le paiement en ligne (PayPal, PayBox, Ogone, Bluepaid). Cela évite à nos clients d'avoir à souscrire un contrat au près d'un fournisseur supplémentaire : ils souscrivent un contrat uniquement auprès de leur banque. Par contre, pour les banques dont l'intermédiaire est une société tierce, OpenFlyers s'nterface avec la solution. C'est le cas, par exemple, pour PayBox.
• Bien vérifier les numéros de version avant de souscrire à une solution. Derrière un numéro de version "commercial" peut se cacher un changement de prestataire ou de technologie utilisée pour l'interfaçage. De ce fait, cela peut rendre incompatible telle version avec OpenFlyers.
• Ne surtout pas souscrire à un contrat de "VAD (vente à distance) sur internet". Car il n'inclut pas l'interface web dite de "TPE virtuel".

Modules de paiement interfacés par OpenFlyers :

• AXEPTA utilisé par les banques suivantes :
  • BNP Paribas
• CMCIC version 1.2open et version 3.5 (nom commercial : Monetico Paiement) utilisés par les banques suivantes :
  • Crédit Mutuel
  • CIC
• PAYBOX utilisé par les banques suivantes :
  • Crédit Agricole (e-transactions). A noter que la procédure de mise en place "Paybox Vision" est lourde et impose des actions de la part du gestionnaire de la structure. De plus, elle nécessite de disposer d'une adresse qui ne soit pas en @free.fr ou @orange.fr.
  • Crédit Coopératif
• PAYLINE utilisé par les banques suivantes :
  • Crédit Mutuel (citélis)
• PAYZEN utilisé par les banques suivantes :
  • La Banque Postale (Scellius)
  • La Société Générale (sogecommerce)
• SIPS ATOS v. 1 utilisé par les banques suivantes :
  • Banque de Savoie (remplacé par systempay)
  • Banque Populaire (cyberplus paiement) (remplacé par systempay)
  • BNP Paribas (mercanet) (remplacé par SIPS ATOS v. 2)
  • Crédit du Nord (webaffaires)
  • Crédit Lyonnais (sherlocks)
  • Crédit Mutuel
  • HSBC (elysnet)
  • La Poste (scellius)
  • Société Générale (sogenactif v. 1)
• SIPS ATOS v. 2 utilisé par les banques suivantes :
  • BNP Paribas (mercanet) (remplacé par AXEPTA)
  • Société Générale (sogenactif v. 2)
• SP PLUS utilisé par les banques suivantes :
  • Caisse d'Epargne
• SYSTEMPAY utilisé par les banques suivantes :
  • Banque de Savoie
  • Banque Populaire (cyberplus paiement)
  • Caisse d'Epargne

Procédures TPE

Procédure CMCICv3

• Aller sur l'interface d'administration
• Dans le champ Identifiant saisir l'identifiant communiqué par e-mail par la banque
• Dans le champ Mot de passe saisir le mot de passe communiqué par e-mail par la banque
• Cliquer sur le bouton VALIDER

Une fois connecté, vous êtes soit sur l'interface back-office de production soit sur l'interface back-office de test. L'interface back-office de test est reconnaissable aux mots "test" qui apparaissent un peu partout dans le bandeau supérieur de l'interface.

• Si l'interface indique Votre identifiant n'est associé à aucun TPE sur l'environnement de XXX, basculer sur l'autre interface en cliquant à droite dans la boite Environnement sur le lien Cliquez ici pour basculer vers le Tableau de Bord de XXX.
• Cliquer sur le menu Paramétrage.
• Cliquer sur le sous-menu Clé de sécurité.
• Sélectionner l'e-mail sur lequel vous souhaitez recevoir le code de téléchargement.
• Cliquer sur le bouton VALIDER.

Attention : Ne pas fermer la page Obtention de la clé de sécurité permettant de récupérer la clé

• Copier depuis sa messagerie e-mail le Code de confirmation
• Coller ce code dans l'interface Obtention de la clé de sécurité
• Cliquer sur le bouton VALIDER
• Cliquer sur le lien Télécharger la clé de sécurité
• Enregistrer le fichier XXXXXXX.key
• Nous transmettre par e-mail ce fichier en nous précisant si vous l'avez obtenu depuis l'interface de production ou depuis l'interface de test.

Procédure Paybox Vision

Cette procédure débute après que l'identifiant et le mot de passe ait été changé conformément aux préconisations d'e-transactions. L'identifiant doit correspondre à une adresse e-mail autre que @free.fr ou @orange.fr

• Aller sur l'interface d'administration Vision de production
• Dans le champ Login, saisir l'identifiant qui correspond normalement à une adresse e-mail
• Dans le champ Mot de passe, saisir le mot de passe qui a été préalablement modifié
• Cliquer sur le bouton Se connecter
• Cliquer sur le menu représentant une clé de mécanicien.
• Dans la zone de gauche cliquer sur les icônes pour déplier les éléments jusqu'à faire apparaitre un élément avec une icône caddy puis cliquer sur cette icône pour faire apparaitre un formulaire dans la zone principale à droite
• Dans le tableau, copier/coller sur un fichier texte les champs Numéro du magasin, Numéro de rang et Identifiant Paybox. Attention : Numéro de rang doit être recopié sur 2 chiffres et non pas trois (exemple : 01).
• Dans le tableau, dans le champ Réception du ticket de paiement sélectionner Inactif.
• Cliquer sur le bouton Enregistrer
• Tout en haut de l'interface, saisir des caractères dans le champ Phrase de passe de façon à ce que le bouton à droite du champ passe à "Fort"
• Cliquer sur le bouton en-dessous du champ intitulé Générer la clé
• Une fois la clé générée, recopier le contenu de la clé qui apparait en-dessous du bouton Générer la clé à côté du champ Clé :
• Valider l'e-mail reçu pour acceptation de la clé
• Transmettre par e-mail à OpenFlyers les informations suivantes :
  • Numéro du magasin
  • Numéro de rang
  • Identifiant Paybox
  • Clé

Procédure SIPS ATOS v2

• Aller sur l'interface de téléchargement soit de :
  • SIPS Worldline
  • BNP Paribas
• Dans le champ Utilisateur, saisir l'identifiant de connexion communiqué par la banque
• Dans le champ Mot de passe, saisir le mot de passe de connexion communiqué par la banque
• Cliquer sur le bouton Se connecter

S'il s'agit de la première connexion, le système demandera de changer le mot de passe

• En haut à droite, cliquer sur le bouton Clés secrètes ou GESTION DES CLÉS
• Cliquer sur le bouton DEMANDE DE GENERATION
• Sauvegarder le fichier et le transmettre par email à OpenFlyers.

Qualité de service d'un TPE

Selon les Terminal de Paiement Électroniques virtuel, certains systèmes n'effectuent pas de renvoi de l'avis de débit aux serveurs dans le cas ou le premier envoi à échouer. Ce type de situation est rare mais peut arriver (problème de liaison internet par exemple ou indisponibilité momentanée du serveur recevant les avis de transactions). A contrario, les bons systèmes enregistrent les échecs, attendent un certain délai puis effectuent une nouvelle tentative d'envoi.

De même certains systèmes envoient un e-mail d'erreur lorsque la transaction n'est pas prise en compte par la plateforme OpenFlyers.

Il est donc recommandé de vérifier auprès de sa banque si la solution TPE proposée effectue ce type de surveillance et de renvoi systématique.

Si en exploitation, vous êtes confronté à un problème de prise en compte par votre plateforme OpenFlyers d'un paiement effectué par un utilisateur, il faut vérifier que cette transaction a bien eu lieu. Pour cela, il faut se connecter à l'interface de gestion du TPE proposé par la banque, retrouver la ligne correspondant à la transaction. Cette ligne doit comporter un message d'anomalie indiquant que le serveur OpenFlyers n'a pas accusé réception de l'avis de transaction.

A la suite de quoi, vous pouvez nous remonter l'anomalie pour que nous consultions les logs et ainsi que nous vérifions s'il n'y a pas eu un bug dans OpenFlyers bloquant l'enregistrement de la transaction. Il existe également un rapport listant les tentatives de paiements qui permet de vérifier s'il y a bien eu une tentative de paiement d'initiée côté OpenFlyers.

Si à la suite de notre investigation, nous n'avons pas retrouvé d'enregistrement d'avis de transaction cela veut dire que le message n'est pas parvenu au serveur et que vous êtes sur un système de TPE qui n'effectue pas de nouvel envoi en cas d'échec (cf. ci-dessus).

Nous vous recommandons alors de faire remonter le problème auprès de votre banque pour qu'ils améliorent leur processus en mettant en place une surveillance des avis en échec et un renouvellement de l'envoi.

Liste des TPE effectuant plusieurs tentatives d'avis de paiement

• systempay

Workflow

L'utilisation du logiciel OpenFlyers nécessite la mise en place d'une chronologie des actions quotidiennes et annuelles.

Workflow des actions quotidiennes

• Le première action chronologique concerne la réservation qui intervient en amont de la réalisation d'une activité.
• Ensuite, vient la saisie d'activité qui se fait soit :
  • en 2 phases :
    • Ouverture de l'activité avant de débuter l'activité
    • Puis fermeture de l'activité après la réalisation de l'activité
  • en 1 phase :
    • Fermeture de l'activité qui se fait à l'issue de la réalisation de l'activité

Dans le cas des activités aéronautiques, nous recommandons de donner comme consigne aux pilotes de saisir les vols dans OpenFlyers et ensuite de recopier les valeurs affichées par OpenFlyers sur le carnet de route. En effet, le document qui fait foi est le carnet de route. Cependant, c'est OpenFlyers qui est normalement utilisé pour faire le total des heures dans le cadre du suivi de la maintenance. De ce fait, il est important que les données dans OpenFlyers et sur le carnet de route correspondent rigoureusement. Or, le risque d'erreur est plus faible lorsqu'on recopie des éléments affichés sur un écran plutôt que si on recopie sur un écran des éléments écrits sur un papier. En plus, OpenFlyers fait des calculs automatiquement. En saisissant d'abord sur OpenFlyers, le pilote n'a plus à faire de calcul. Il s'évite ainsi une source d'erreur.

Quelque soit le mode de saisie (ouverture+fermeture ou fermeture uniquement), c'est la saisie de la fermeture qui déclenche la facturation. L'ouverture de l'activité permet d'informer les autres utilisateurs :

• de la prise en compte d'une ressource et donc de son indisponibilité pour une autre activité
• des intentions au cours de la réalisation de l'activité
• du temps d'utilisation prévu (et donc de l'horaire de retour prévu)
• du trajet prévu

Ces informations peuvent être utiles dans un but de sécurité.

A noter que la facturation peut être déclenchée en amont au vu des réservations et non pas de la réalisation de l'activité.

Un autre élément du workflow concerne l'encaissement des paiements des utilisateurs ou la vente de produits. Ces opérations sont déconnectées de la chronologie réservation/réalisation d'une activité.

Workflow des actions hebdomadaires/mensuelles

En aval de la réalisation de l'activité, intervient les actions liées à la comptabilité. Il est indispensable de suivre la démarche suivante pour garantir la confiance des parties prenantes (utilisateurs, gestionnaires et l'éditeur du logiciel OpenFlyers).

Validation des écritures

Il faut valider régulièrement l'ensemble des écritures par pointage systématique. Cela concerne :

• La validation des saisies d'activités
• La validation des ventes de produits.
• La validation des encaissements
• La validation des saisies de flux comptables divers.

Cette validation doit être adaptée en fonction de la taille de la structure et des ressources humaines disponibles pour effectuer cette tâche. Dans une petite structure, une validation tous les mois est acceptable, dans une grande structure, une validation toutes les semaines est recommandée.

Concernant la validation des saisies d'activités comme par exemple les vols effectués sur les aéronefs, cette dernière doit être effectuée au plus tard, pour un aéronef considéré, avant la pose d'une APRS (Approbation Pour Remise en Service) afin de garantir le bon calcul des heures de vols de l'aéronef concerné.

Concernant la validation des ventes de produits, cette dernière doit être faite en fonction du type de produit vendu. S'il s'agit d'un produit physique remis en main propre, alors la validation devrait avoir lieu lors de la remise du produit. S'il s'agit d'un produit immatériel, comme des packs d'heures d'activité, alors la validation devrait être décaler de quelques jours, voir d'une semaine, afin de permettre au client d'exercer son droit de rétractation. Néanmoins, cette validation doit intervenir à intervalle régulier pour éviter toute abus de la part des utilisateurs.

Concernant la validation des encaissements, cette dernière s'effectue normalement lors du pointage du type d'encaissement considéré. Ainsi pour les chèques, cela permet de générer le bordereau de remise pour la banque.

Concernant les flux comptables divers, dès qu'ils touchent un compte client, ils devraient être validés au plus tôt afin de garantir au client qu'il n'y aura pas de "disparition" à posteriori de ce flux. Si par la suite une erreur est détectée sur ce flux, il suffira de saisir un flux correctif permettant d'annuler l'erreur. Cette pratique est imposée par l'inaltérabilité des données.

Saisie des factures/paiements fournisseurs

La saisie des factures fournisseurs et de leur paiement sont à effectuer si la structure a décidé de gérer les charges dans OpenFlyers.

Nous recommandons :

• De saisir les factures fournisseurs après leur paiement.
• D'effectuer la saisie des paiements fournisseurs au vu du relevé de banque, donc normalement, une fois par mois.

Workflow des actions annuelles

Validation des charges

Lorsque les charges sont gérées dans OpenFlyers, nous recommandons de valider les factures et les paiements fournisseurs juste avant la clôture de la comptabilité.

En effet, il n'est pas utile de les valider plus tôt car :

• Ils n'ont pas d'impact sur les utilisateurs.
• Il est préférable d'attendre que les comptes de trésorerie soient réputés exactes et que le solde des comptes fournisseurs aient été vérifiés. Cela laisse la possibilité de modifier une saisie de facture ou de paiement fournisseur qui aurait été mal ventilée.

Clôture/ouverture de l'exercice comptable

Lors du changement d'exercice comptable, il est nécessaire d'effectuer certaines opérations comptables dans OpenFlyers et de procéder à la clôture de l'exercice précédent.

Ces opérations n'ont pas besoin d'être effectuées dès le changement d'exercice. En effet, il est possible de continuer à saisir sur le nouvel exercice sans que le précédent soit clôturer.

De plus, ces opérations nécessitent un paramétrage préalable de la plateforme afin de garantir que les écritures comptables seront correctement exportées dans un ou plusieurs fichiers en vu de leur archivage ou de leur import dans un logiciel de comptabilité.

Un mécanisme de vérification en place dans le logiciel OpenFlyers empêche de désactiver tout compte dont le solde n'est pas nul et dont les écritures n'ont pas été exportées. Cela permet de garantir qu'on garde la "vue" sur tout ce qui impacte le compte d'exploitation en cours et le bilan.

En corolaire, il n'est donc possible de désactiver des utilisateurs ou des ressources que lorsque leurs comptes sont eux-mêmes désactivables.

Aussi, nous recommandons de fixer une politique de gestion des utilisateurs consistant à n'effectuer d'opération de "désactivation" qu'après un décalage d'une ou plusieurs années sans présence dans la structure. Il est judicieux de fixer ce décalage dans tout document contractuel comme les conditions générales de ventes, les statuts ou règlements intérieurs. Ainsi, la "mise à 0" du solde du compte en passant en "pertes et profits" ne pourra être remis en cause par l'utilisateur ou le client à posteriori.

Voir les procédures correspondantes.