Voir la source de 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 :
#La mise en place de la réservation qui est relativement simple à appréhender
#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.

=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.

=Mettre en place la [[Introduction#La_gestion_d.27activit.C3.A9_avec_OpenFlyers|gestion d'activité]] sur OpenFlyers=
La mise en place de la [[Introduction#La_gestion_d.27activit.C3.A9_avec_OpenFlyers|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 des écritures qui seront gérées par OpenFlyers==
Cela peut être :
#La saisie de l'activité elle-même et donc la génération du chiffre d'affaire au travers des factures clients et des écritures comptables qui sont automatiquement générées avec l'activité
#Les factures fournisseurs
Le premier point implique qu'OpenFlyers est également utilisé pour la saisie des encaissements clients et le second point implique qu'OpenFlyers est également utilisé pour la saisie des paiements fournisseurs.

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 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" dans les cuisines : 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 [[FAQ_client#Comment_fonctionne_le_forfait_param.C3.A9trage_.3F|forfait paramétrage]]. Les avantages sont les suivants :
*Vous gagnez pas 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 [[OpenFlyers_Trainings|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 [http://doc-en.openflyers.com/index.php?title=Export_generator 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.

Vous pouvez retrouver le tarif du forfait paramétrage dans notre [http://www.openflyers.com/doc/catalogue-tarifaire.pdf 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 :
#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
#Nous créons les factures correspondantes le cas échéant (selon votre abonnement) puis vous les payez.
#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.
#Vous nous retournez le questionnaire paramétrage rempli.
#Nous parcourons le questionnaire pour vérifier qu'il est complet. Si ce n'est pas le cas, nous vous demandons des précisions.
#Une fois que le questionnaire est retourné complet et que votre plateforme est sous version 3, nous nous engageons à mettre en place le paramétrage initial sous 15 jours.
#Ce paramétrage sera suivi par une [[#Tester_la_configuration|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.
#Une fois que vous aurez terminé la validation du paramétrage, nous pourrons procéder, à votre demande et sans frais supplémentaire, à une [[#Nettoyer_la_base_de_donn.C3.A9es_avant_le_passage_en_production|suppression complète des écritures comptables et d'activités]] qui auront été saisies pour tester le paramétrage.

==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 [[How_to_communicate_with_OpenFlyers#Rapporter_un_.C3.A9cart_de_param.C3.A9trage|guide de rapport d'anomalie de paramétrage]].

==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 les écritures comptables, les écritures d'activités (vols dans le cas d'une structure aéronautique) créées durant les tests de validation du paramétrage.

==Passer en production==
Le passage en production doit se faire à une date donnée et définie à l'avance (idéalement un 1er janvier).
Cela suppose :
*Qu'avant cette date, toutes les écritures sont saisies dans l'ancien système de gestion utilisé
*A partir de cette date, toutes les écritures sont saisies dans OpenFlyers

Attention : lors du passage en production (idéalement le 1er janvier donc), 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 :
#Passer en production sur la saisie des vols à la date convenue avec des à nouveaux de comptes clients à 0 (donc faux).
#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 [[#Rapatrier_les_.C3.A0_nouveaux|à nouveaux ne seront pas mis à jour]].

==Rapatrier les à nouveaux==
Le rapatriement des à nouveaux ne doit être effectué qu'une fois que la comptabilité de l'exercice précédent a été consolidée et validée. Cette opération attend donc souvent plusieurs semaines avant de pouvoir être réalisée.

La meilleure méthode pour effectuer cette opération est d'importer un fichier csv contenant les à nouveaux 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.

==[[#Workflow|Mettre en place un workflow adapté à OpenFlyers]]==
Une fois en production, OpenFlyers recommande de [[#Workflow|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é.

=Mettre en place un TPE virtuel=
Voici comment procéder pour créer un TPE virtuel (Terminal de Paiement Electronique en ligne) :
#Contacter votre banque pour :
#*connaitre le système qu'elle utilise et nous l'indiquer afin de vérifier qu'[[#Liste_des_syst.C3.A8mes_impl.C3.A9ment.C3.A9s_par_OpenFlyers|OpenFlyers est bien compatible]].
#*obtenir son accord de principe sur la mise en place d'un TPE virtuel (normalement cela ne devrait pas poser de problème)
#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.
#Une fois que nous vous avons répondu positivement, il vous appartient de nous confirmer votre demande de mise en place
#Nous éditons la facture correspondant au coût de mise en place (voir notre [http://www.openflyers.com/doc/catalogue-tarifaire.pdf 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 :
#*Adresse du site internet, adresse du site marchand : il s'agit de l'adresse de votre plateforme OpenFlyers par exemple http://demo.openflyers.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 : 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 contact OpenFlyers.
#Vous payez la facture
#Vous nous communiquez les éléments de votre banque nous permettant de raccorder OpenFlyers à votre TPE virtuel.
#Nous effectuons le raccordement
#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.

==Liste des systèmes implémentés par OpenFlyers==
OpenFlyers a implémenté jusqu'à présent les systèmes suivants :
*CMCIC version 1.2open et version 3 (uniquement sous OpenFlyers 3.1) utilisé par le Crédit Mutuel et le CIC (mais pas toujours, cela dépend des agences)
*PAYBOX (uniquement sous version 3.1)
**Crédit Agricole (e-transactions)
*PAYLINE utilisé par Citélis du Crédit Mutuel.
*SIPS ATOS utilisé par plusieurs banques. Voici les cas que nous avons rencontré utilisant SIPS d'ATOS :
**BNP Paribas
**Crédit Agricole (e-transactions)
**Crédit Mutuel
**LA POSTE
**Société Générale
*SP PLUS utilisé par la Caisse d'Epargne

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

==Workflow des actions quotidiennes==
Ainsi, concernant la comptabilité, il est indispensable de suivre la démarche suivante pour garantir la confiance des parties prenantes (utilisateurs, gestionnaires et éditeur logiciel) :
*Il faut valider régulièrement l'ensemble des écritures par pointage systématique. Cela concerne :
**[[Introduction#Validation_de_la_saisie_de_l.27activit.C3.A9|La validation des saisies d'activités]]
**[[Product_sale_manager3#Validation_d.27un_panier|La validation des ventes de produits]]
**[[OF_Use_Accounting3#Validation_des_r.C3.A8glements_clients|La validation des encaissements]]
**[[OF_Use_Accounting3#Validation_d.27un_flux|La validation des saisies de flux comptables divers]]
Cette validation doit être adaptée en fonction de la taille de structure et de 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 avant pour un aéronef considéré avant la dépose d'une APRS afin de garantir le bon calcul des heures de vols effectuées par l'aéronef considéré.

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 assure la traçabilité des écritures.

==Workflow des actions annuelles==
En fin d'exercice, il est nécessaire de clôturer la comptabilité. Cette action nécessite d'avoir effectué des opérations préliminaires qui permettent de garantir notamment que les écritures comptables seront exportées dans un ou plusieurs fichiers en vu de leur archivage.

Le 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 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.

C'est également juste avant la clôture de la comptabilité que nous recommandons de valider les factures fournisseurs. Il n'est pas utile de valider plus tôt ces écritures car elles n'ont pas d'impact sur les utilisateurs. Nous recommandons donc de retarder au plus tard cette validation, notamment une fois que les comptes de trésorerie sont réputés exactes et que le solde des comptes fournisseurs a été vérifié.