Facturation des clients : Différence entre versions
(→Tarification et facturation) |
(→Cascade d'écritures comptables) |
||
(93 révisions intermédiaires par 3 utilisateurs non affichées) | |||
Ligne 5 : | Ligne 5 : | ||
Il existe deux types de facturation : | Il existe deux types de facturation : | ||
− | * [[ | + | * [[Facturation des heures de vol|La facturation d'un vol]] qui s'effectue lors de la saisie d'une [[Introduction#Modes_de_saisie_ouverture+fermeture_ou_fermeture_seule|fermeture de vol]]. |
− | *La facturation d'une vente de produit qui s'effectue lors de la saisie d'un [[ | + | *La facturation d'une vente de produit qui s'effectue lors de la saisie d'un [[Gestion des produits et des ventes#Achat_de_produit_non_stocké|achat de produit]]. |
− | En plus de la génération d'une ou [[#Factures_multiples|plusieurs factures]], des écritures comptables sont automatiquement générées. Le nombre d'écritures générées dépend de la [[ | + | En plus de la génération d'une ou [[#Factures_multiples|plusieurs factures]], des écritures comptables sont automatiquement générées. Le nombre d'écritures générées dépend de la [[Écritures comptables3#Fusion_des_écritures_comptables|fusion des écritures]]. |
+ | |||
+ | =Alertes générées par le moteur de tarification= | ||
+ | |||
+ | ==L'utilisateur n'a pas de compte de type XXX== | ||
+ | Cette alerte s'affiche lorsqu'une règle de tarification est applicable et que le compte XXX est manquant pour l'utilisateur concerné. | ||
+ | |||
+ | Une règle est considérée comme applicable à partir du moment où le domaine d'application de la règle la rend applicable pour la saisie considérée. Une règle peut être applicable sans générer forcément une écriture comptable. C'est le cas lorsque le montant de l'écriture comptable est nul. | ||
=Factures multiples= | =Factures multiples= | ||
Ligne 21 : | Ligne 28 : | ||
Dans la version 3 d'OpenFlyers, lors de la validation d'une facturation client (heures de vols, produits non stockés, etc.), la facture associée est créée avec un numéro de facture unique. Ce numéro de facture correspond au dernier numéro de facture client créé augmenté de 1. Ainsi, si la facture précédente avait le numéro 307, alors la nouvelle facture a le numéro 308. Cet algorithme est conforme à la [http://vosdroits.service-public.fr/professionnels-entreprises/F23208.xhtml législation française concernant la numérotation des factures] qui prévoit que : | Dans la version 3 d'OpenFlyers, lors de la validation d'une facturation client (heures de vols, produits non stockés, etc.), la facture associée est créée avec un numéro de facture unique. Ce numéro de facture correspond au dernier numéro de facture client créé augmenté de 1. Ainsi, si la facture précédente avait le numéro 307, alors la nouvelle facture a le numéro 308. Cet algorithme est conforme à la [http://vosdroits.service-public.fr/professionnels-entreprises/F23208.xhtml législation française concernant la numérotation des factures] qui prévoit que : | ||
''la numérotation des factures est représentée par un numéro unique basé sur une séquence chronologique continue, sans rupture'' | ''la numérotation des factures est représentée par un numéro unique basé sur une séquence chronologique continue, sans rupture'' | ||
+ | |||
+ | =[[Utilisation de la comptabilité#Opérations_sur_les_tarifs|Gestion des tarifs]]= | ||
=Moteur de tarification et de facturation= | =Moteur de tarification et de facturation= | ||
==Cascade d'écritures comptables== | ==Cascade d'écritures comptables== | ||
− | Les moteurs de | + | Les moteurs de facturation des activités et des produits fonctionnent avec le concept d'''écritures en cascade''. |
+ | |||
+ | Introduction du principe : | ||
+ | *En général, dans une facturation, L'utilisateur final est normalement débité et le compte produit correspondant crédité | ||
+ | *Si l'utilisateur a droit à ce qu'une partie du coût de l'activité soit facturé à l'organisme dont il dépend, une autre écriture comptable vient créditer son compte utilisateur et débiter le compte client de l'organisme concerné | ||
+ | *Enfin, les écritures sont [[Gestion-des-écritures-comptables#Fusion_des_écritures_comptables|fusionnées]] de telle sorte que l'utilisateur ne sera finalement débité que du montant devant être réellement à sa charge. | ||
− | + | Les détails du principe de fonctionnement sont les suivants : | |
*Les règles de tarification s'appliquent les unes après les autres, de la première à la dernière en partant du haut, lorsqu'elles sont applicables selon les critères de leur domaine | *Les règles de tarification s'appliquent les unes après les autres, de la première à la dernière en partant du haut, lorsqu'elles sont applicables selon les critères de leur domaine | ||
+ | ** Les domaines d'application pour la facturation des activités sont : Les profils en place gauche et/ou en place droite, les types de ressources, les types de vols, les types de vols exclus | ||
+ | ** Les domaines d'application pour la facturation des produits sont : Les profils, les produits commandés | ||
+ | ** Le symbole * dans un domaine signifie "N'importe quel domaine" | ||
*Chaque règle peut donc générer un couple d'écriture débit/crédit | *Chaque règle peut donc générer un couple d'écriture débit/crédit | ||
− | *Une fois que toutes les écritures sont générées elles sont [[ | + | *Une fois que toutes les écritures sont générées, elles sont [[Gestion-des-écritures-comptables#Fusion_des_écritures_comptables|fusionnées]] afin de diminuer leur nombre et de supprimer les écritures qui s'annulent. |
− | L'objectif est de faciliter la construction des règles de tarification en | + | L'objectif est de faciliter la construction des règles de tarification en partant du général pour aller vers le spécifique : |
*Il faut d'abord créer une ou des règles de tarification générales. Ainsi, pour la tarification des heures de vols, il faut d'abord définir les tarifs en "solo". Pour faire un parallèle avec la technique de façonnage de la poterie, on construit ainsi d'abord une forme homogène générale. | *Il faut d'abord créer une ou des règles de tarification générales. Ainsi, pour la tarification des heures de vols, il faut d'abord définir les tarifs en "solo". Pour faire un parallèle avec la technique de façonnage de la poterie, on construit ainsi d'abord une forme homogène générale. | ||
*Ensuite, on crée des règles de tarification spécifiques qui vont "détourner" les règles générales soit en redirigeant le débit ou le crédit, soit en l'annulant soit en en modifiant le montant. Toujours dans le parallèle avec la poterie, on façonne alors les particularités en rajoutant des trous ou des volumes spécifiques. | *Ensuite, on crée des règles de tarification spécifiques qui vont "détourner" les règles générales soit en redirigeant le débit ou le crédit, soit en l'annulant soit en en modifiant le montant. Toujours dans le parallèle avec la poterie, on façonne alors les particularités en rajoutant des trous ou des volumes spécifiques. | ||
+ | *Enfin, dans certains cas et notamment lorsque la structure est assujettie à la TVA, on calcule un montant net applicable et on en déduit la TVA. | ||
+ | |||
+ | |||
+ | |||
+ | Voici un exemple du résultat possible avec le fonctionnement en cascade : | ||
+ | |||
+ | Nous supposons que l'utilisateur effectue une activité dont le coût est de 200 €. La moitié de cette activité, soit 100 € est prise en charge par un organisme tiers. | ||
+ | |||
+ | *Dans un premier temps, grâce à une règle générale, l'utilisateur sera débité de 200 € et le compte produit crédité de 200 € : | ||
+ | {| class="wikitable" | ||
+ | !Compte!!Débit!!Crédit | ||
+ | |- | ||
+ | |Utilisateur||200.00 €|| | ||
+ | |- | ||
+ | |Compte produit||||200.00 € | ||
+ | |} | ||
+ | *Dans un second temps, une nouvelle règle particulière va identifier que l'utilisateur rentre dans le cadre où un organisme tiers doit prendre en charge la moitié du coût. Cette règle va générer une écriture qui va débiter le compte de l'organisme tiers de 100 € et créditer le compte de l'utilisateur de 100 €. | ||
+ | {| class="wikitable" | ||
+ | !Compte!!Débit!!Crédit | ||
+ | |- | ||
+ | |Utilisateur||200.00 €|| | ||
+ | |- | ||
+ | |Compte produit||||200.00 € | ||
+ | |- | ||
+ | |Organisme||100.00 €|| | ||
+ | |- | ||
+ | |Utilisateur||||100.00 € | ||
+ | |} | ||
+ | *Dans un troisième et dernier temps, les écritures seront fusionnées. | ||
+ | |||
+ | Au final, les écritures comptables générées devraient être les suivantes s'il n'y a pas de gestion de la TVA : | ||
+ | {| class="wikitable" | ||
+ | !Compte!!Débit!!Crédit | ||
+ | |- | ||
+ | |Utilisateur||100.00 €|| | ||
+ | |- | ||
+ | |Organisme||100.00 €|| | ||
+ | |- | ||
+ | |Compte produit||||200.00 € | ||
+ | |} | ||
+ | |||
+ | Au final, les écritures comptables générées devraient être les suivantes s'il y a gestion de la TVA (exemple avec une TVA à 20%) : | ||
+ | {| class="wikitable" | ||
+ | !Compte!!Débit!!Crédit | ||
+ | |- | ||
+ | |Utilisateur||100.00 €|| | ||
+ | |- | ||
+ | |Organisme||100.00 €|| | ||
+ | |- | ||
+ | |Compte produit||||160.00 € | ||
+ | |- | ||
+ | |TVA collectée (445710) ||||40.00 € | ||
+ | |} | ||
==Fonctionnement des variables associées aux formules de tarification== | ==Fonctionnement des variables associées aux formules de tarification== | ||
Ligne 69 : | Ligne 139 : | ||
!Formule!!Variable!!Nom de la règle!!Ressources concernées!!Types de vol concernés!!Compte à débiter!!Compte à créditer | !Formule!!Variable!!Nom de la règle!!Ressources concernées!!Types de vol concernés!!Compte à débiter!!Compte à créditer | ||
|- | |- | ||
− | |50||X||Règle 1|| | + | |50||X||Règle 1||Ressource F-GAX||Local||Pilote||Ressource F-GAX |
|- | |- | ||
− | |@X+100||||Règle 2|| | + | |@X+100||||Règle 2||Ressource F-GAX||Instruction||Pilote||Ressource F-GAX |
|- | |- | ||
− | |@X+150||||Règle 3|| | + | |@X+150||||Règle 3||Ressource F-TYH||Local||Pilote||Ressource F-TYH |
|- | |- | ||
|} | |} | ||
− | ====Saisie de vol avec comme types "Local" + "Instruction" et ressource " | + | ====Saisie de vol avec comme types "Local" + "Instruction" et ressource "Ressource F-GAX"==== |
Dans cet exemple, les règles 1 et 2 s'appliquent. | Dans cet exemple, les règles 1 et 2 s'appliquent. | ||
Ligne 83 : | Ligne 153 : | ||
Au niveau du calcul du coût de vol, cela va procéder ainsi : | Au niveau du calcul du coût de vol, cela va procéder ainsi : | ||
# Récupération de la règle 1, la formule donne 50 | # Récupération de la règle 1, la formule donne 50 | ||
− | # Le compte "Pilote" est débité de 50 puis le compte " | + | # Le compte "Pilote" est débité de 50 puis le compte "Ressource F-GAX" est crédité de 50 conformément à la règle 1 |
# Stockage en mémoire de 50 dans la variable X | # Stockage en mémoire de 50 dans la variable X | ||
# Récupération de la règle 2, la formule va donner X+100 soit 50+100 | # Récupération de la règle 2, la formule va donner X+100 soit 50+100 | ||
− | # Le compte "Pilote" est débité de 150 puis le compte " | + | # Le compte "Pilote" est débité de 150 puis le compte "Ressource F-GAX" est crédité de 150 conformément à la règle 2 |
− | ====Saisie de vol avec comme type "Instruction" et ressource " | + | ====Saisie de vol avec comme type "Instruction" et ressource "Ressource F-GAX"==== |
Dans cet exemple, seule la règle 2 s'applique. | Dans cet exemple, seule la règle 2 s'applique. | ||
Ligne 94 : | Ligne 164 : | ||
Au niveau du calcul du coût de vol, cela va procéder ainsi : | Au niveau du calcul du coût de vol, cela va procéder ainsi : | ||
# Récupération de la règle 2, la formule va donner donner X+100 soit 0+100 vu qu'il n'y a pas eu de stockage en mémoire de la variable X et que la règle 1 n'est pas applicable | # Récupération de la règle 2, la formule va donner donner X+100 soit 0+100 vu qu'il n'y a pas eu de stockage en mémoire de la variable X et que la règle 1 n'est pas applicable | ||
− | # Le compte "Pilote" est débité de 100 puis le compte " | + | # Le compte "Pilote" est débité de 100 puis le compte "Ressource F-GAX" est crédité de 100 conformément à la règle 2 |
− | ====Saisie de vol avec comme type "Instruction" et ressource " | + | ====Saisie de vol avec comme type "Instruction" et ressource "Ressource F-TYH"==== |
Dans cet exemple, seule la règle 3 s'applique. | Dans cet exemple, seule la règle 3 s'applique. | ||
Ligne 102 : | Ligne 172 : | ||
Au niveau du calcul du coût de vol, cela va procéder ainsi : | Au niveau du calcul du coût de vol, cela va procéder ainsi : | ||
# Récupération de la règle 3, la formule va donner donner X+150 soit 0+150 vu qu'il n'y a pas eu de stockage en mémoire de la variable X | # Récupération de la règle 3, la formule va donner donner X+150 soit 0+150 vu qu'il n'y a pas eu de stockage en mémoire de la variable X | ||
− | # Le compte "Pilote" est débité de 150 puis le compte " | + | # Le compte "Pilote" est débité de 150 puis le compte "Ressource F-TYH" est crédité de 150 conformément à la règle 3 |
===Exemple d'application et de non-application pour la tarification des produits=== | ===Exemple d'application et de non-application pour la tarification des produits=== | ||
Ligne 177 : | Ligne 247 : | ||
* Y affecter un groupe de facturation à des règles autre que 1 et 2. Par exemple 3. | * Y affecter un groupe de facturation à des règles autre que 1 et 2. Par exemple 3. | ||
* Répéter ce processus pour chacune des différentes factures à créer. | * Répéter ce processus pour chacune des différentes factures à créer. | ||
+ | |||
+ | ==Facturation périodique== | ||
+ | |||
+ | ===Fonctionnement de la facturation périodique=== | ||
+ | |||
+ | La facturation périodique se déclenche tous les jours aux alentours de minuit, fuseau Europe/Paris. Elle procède ainsi : | ||
+ | * Récupération de toutes les [[#Ajout_d'une_tâche_de_facturation_périodique|tâches de facturation périodique]] ayant la règle "every ..." | ||
+ | * Analyse de la règle "every ..." pour vérifier si la tâche doit être exécutée ou non pour ce jour. Si exécution : | ||
+ | ** Récupération de toutes les règles de tarification rattachées à la tâche exécutée | ||
+ | ** Pour chaque règle trouvée : | ||
+ | *** Analyse de la [[#Requête_SQL_de_facturation_périodique|requête affectée à la règle]] pour initialiser des variables nécessaires pour la tarification | ||
+ | *** [[#Cascade_d'écritures_comptables|Traduction de la règle et tarification]] | ||
+ | |||
+ | ===Mise en place de la facturation périodique=== | ||
+ | |||
+ | ====Ajout d'un produit pour la facturation périodique==== | ||
+ | |||
+ | * Aller dans '''Admin > Ventes > Produits''' | ||
+ | * Créer un produit : | ||
+ | ** '''Nom''' : Facturation périodique | ||
+ | ** '''Type de vente''' : '''Produit périodique''' | ||
+ | ** Les autres champs : A paramétrer selon les besoins | ||
+ | |||
+ | ====Ajout d'une tâche de facturation périodique==== | ||
+ | |||
+ | * Aller dans '''Admin > Ventes > Tarification des heures > Facturation périodique''' | ||
+ | * Ajouter une nouvelle ligne | ||
+ | * La colonne '''Evènement''' permet de définir quand va être lancé la tâche. Mettre l'un de ces textes à personnaliser : | ||
+ | **Pour une tâche lancée quotidiennement : '''every(* * *)''' | ||
+ | **Pour une tâche lancée tous les 1er février : '''every(1 2 *)''' | ||
+ | **Pour une tâche lancée tous les 1er d'un mois : '''every(1 X *)'''. Remplacer "X" par le numéro du mois | ||
+ | |||
+ | ====Ajout de règles de tarification pour la tâche de facturation==== | ||
+ | |||
+ | *Ajouter une règle de tarification des heures de vol | ||
+ | *Dans le champ '''Produit''', sélectionner le [[#Ajout_d'un_produit_pour_la_facturation_périodique|produit périodique créé]]. | ||
+ | *Dans le champ '''Tâche''', choisir la [[#Ajout_d'une_tâche_de_facturation_périodique|tâche de facturation périodique]] qui déclenchera la règle de tarification. Il n'est pas possible de sélectionner la tâche "Close flight" à une règle de tarification affectée à un produit périodique. | ||
+ | *Dans le champ '''Requête''', ajouter une [[#Requête_SQL_de_facturation_périodique|requête SQL]] qui va permettre d'obtenir la liste des éléments à facturer. | ||
+ | |||
+ | =====Requête SQL de facturation périodique===== | ||
+ | Les requêtes SQL permettent de définir la liste d'éléments sur lesquels les règles de tarification périodique devront s'appliquer. | ||
+ | |||
+ | Les requêtes doivent être de type '''SELECT''' et le nom de chaque colonne doit être unique. Il est possible d'aliaser ces colonnes à un [[OF_doc-en::CommonFormula#variables|nom de variable]]. | ||
+ | |||
+ | Le résultat retourné doit être le suivant, peu importe l'ordre : | ||
+ | {| class="wikitable centre" | ||
+ | !Donnée attendue!!Présence obligatoire!!Variable affectée!!Valeur par défaut | ||
+ | |- | ||
+ | |Id de la personne en première place||OUI||%PILOT|| | ||
+ | |- | ||
+ | |Id de la personne en seconde place||NON||%PILOT2||0 | ||
+ | |- | ||
+ | |Données métier : Nombre de jour entier d'une réservation||NON||%BOOKING_FULL_DAYS||0 | ||
+ | |- | ||
+ | |Données métier : Id de la réservation. Lorsque l'id est un nombre supérieur à zéro, un [[#Traitement_spécifique_de_la_facturation_périodique|traitement spécifique est réalisé]]||NON||%BOOKING|| | ||
+ | |- | ||
+ | |Données métier||NON||Consulter la [[OF_doc-en::CommonFormula#variables|liste des variables]]|| | ||
+ | |} | ||
+ | |||
+ | Exemple de requête pour facturer les utilisateurs ayant une réservation au jour : | ||
+ | <sql>SELECT person_id AS '%PILOT', instructor_id AS '%PILOT2', id AS '%BOOKING' | ||
+ | FROM booking | ||
+ | WHERE DATE(start_date) = UTC_DATE()</sql> | ||
+ | |||
+ | Exemple de requête pour facturer les utilisateurs : | ||
+ | <sql>SELECT id AS '%PILOT' | ||
+ | FROM person | ||
+ | WHERE activated=1</sql> | ||
+ | |||
+ | ===Traitement spécifique de la facturation périodique=== | ||
+ | |||
+ | La présence de la variable [[#Requête_SQL_de_facturation_périodique|%BOOKING dans la requête SQL d'une règle]] déclenche un traitement supplémentaire qui rattache les écritures générées aux réservations afin de : | ||
+ | * Facturer les réservations qui n'ont pas été déjà facturées | ||
+ | * Facturer le surplus pour les réservations qui ont été modifiées pour rallonger la durée de réservation |
Version actuelle en date du 16 mai 2017 à 08:23
Sommaire
- 1 Présentation
- 2 Alertes générées par le moteur de tarification
- 3 Factures multiples
- 4 Numérotation des factures clients
- 5 Gestion des tarifs
- 6 Moteur de tarification et de facturation
- 6.1 Cascade d'écritures comptables
- 6.2 Fonctionnement des variables associées aux formules de tarification
- 6.3 Mise en place de la facturation client
- 6.4 Facturation périodique
Présentation
L'objet de cette page est de présenter les points généraux de la facturation des clients.
Il existe deux types de facturation :
- La facturation d'un vol qui s'effectue lors de la saisie d'une fermeture de vol.
- La facturation d'une vente de produit qui s'effectue lors de la saisie d'un achat de produit.
En plus de la génération d'une ou plusieurs factures, des écritures comptables sont automatiquement générées. Le nombre d'écritures générées dépend de la fusion des écritures.
Alertes générées par le moteur de tarification
L'utilisateur n'a pas de compte de type XXX
Cette alerte s'affiche lorsqu'une règle de tarification est applicable et que le compte XXX est manquant pour l'utilisateur concerné.
Une règle est considérée comme applicable à partir du moment où le domaine d'application de la règle la rend applicable pour la saisie considérée. Une règle peut être applicable sans générer forcément une écriture comptable. C'est le cas lorsque le montant de l'écriture comptable est nul.
Factures multiples
Les groupes de facturation permettent la séparation des écritures dans différentes factures. Cela permet ainsi de générer automatiquement plusieurs factures lors d'une seule saisie d'une vente de produit ou d'un vol.
L'affectation du groupe de facturation suit les contraintes suivantes :
- Pour un même groupe de facturation, il ne peut y avoir plusieurs comptes client ou utilisateur.
- Les comptes associés à un même groupe de facturation doivent tous être de la même comptabilité.
Numérotation des factures clients
Dans la version 3 d'OpenFlyers, lors de la validation d'une facturation client (heures de vols, produits non stockés, etc.), la facture associée est créée avec un numéro de facture unique. Ce numéro de facture correspond au dernier numéro de facture client créé augmenté de 1. Ainsi, si la facture précédente avait le numéro 307, alors la nouvelle facture a le numéro 308. Cet algorithme est conforme à la législation française concernant la numérotation des factures qui prévoit que : la numérotation des factures est représentée par un numéro unique basé sur une séquence chronologique continue, sans rupture
Gestion des tarifs
Moteur de tarification et de facturation
Cascade d'écritures comptables
Les moteurs de facturation des activités et des produits fonctionnent avec le concept d'écritures en cascade.
Introduction du principe :
- En général, dans une facturation, L'utilisateur final est normalement débité et le compte produit correspondant crédité
- Si l'utilisateur a droit à ce qu'une partie du coût de l'activité soit facturé à l'organisme dont il dépend, une autre écriture comptable vient créditer son compte utilisateur et débiter le compte client de l'organisme concerné
- Enfin, les écritures sont fusionnées de telle sorte que l'utilisateur ne sera finalement débité que du montant devant être réellement à sa charge.
Les détails du principe de fonctionnement sont les suivants :
- Les règles de tarification s'appliquent les unes après les autres, de la première à la dernière en partant du haut, lorsqu'elles sont applicables selon les critères de leur domaine
- Les domaines d'application pour la facturation des activités sont : Les profils en place gauche et/ou en place droite, les types de ressources, les types de vols, les types de vols exclus
- Les domaines d'application pour la facturation des produits sont : Les profils, les produits commandés
- Le symbole * dans un domaine signifie "N'importe quel domaine"
- Chaque règle peut donc générer un couple d'écriture débit/crédit
- Une fois que toutes les écritures sont générées, elles sont fusionnées afin de diminuer leur nombre et de supprimer les écritures qui s'annulent.
L'objectif est de faciliter la construction des règles de tarification en partant du général pour aller vers le spécifique :
- Il faut d'abord créer une ou des règles de tarification générales. Ainsi, pour la tarification des heures de vols, il faut d'abord définir les tarifs en "solo". Pour faire un parallèle avec la technique de façonnage de la poterie, on construit ainsi d'abord une forme homogène générale.
- Ensuite, on crée des règles de tarification spécifiques qui vont "détourner" les règles générales soit en redirigeant le débit ou le crédit, soit en l'annulant soit en en modifiant le montant. Toujours dans le parallèle avec la poterie, on façonne alors les particularités en rajoutant des trous ou des volumes spécifiques.
- Enfin, dans certains cas et notamment lorsque la structure est assujettie à la TVA, on calcule un montant net applicable et on en déduit la TVA.
Voici un exemple du résultat possible avec le fonctionnement en cascade :
Nous supposons que l'utilisateur effectue une activité dont le coût est de 200 €. La moitié de cette activité, soit 100 € est prise en charge par un organisme tiers.
- Dans un premier temps, grâce à une règle générale, l'utilisateur sera débité de 200 € et le compte produit crédité de 200 € :
Compte | Débit | Crédit |
---|---|---|
Utilisateur | 200.00 € | |
Compte produit | 200.00 € |
- Dans un second temps, une nouvelle règle particulière va identifier que l'utilisateur rentre dans le cadre où un organisme tiers doit prendre en charge la moitié du coût. Cette règle va générer une écriture qui va débiter le compte de l'organisme tiers de 100 € et créditer le compte de l'utilisateur de 100 €.
Compte | Débit | Crédit |
---|---|---|
Utilisateur | 200.00 € | |
Compte produit | 200.00 € | |
Organisme | 100.00 € | |
Utilisateur | 100.00 € |
- Dans un troisième et dernier temps, les écritures seront fusionnées.
Au final, les écritures comptables générées devraient être les suivantes s'il n'y a pas de gestion de la TVA :
Compte | Débit | Crédit |
---|---|---|
Utilisateur | 100.00 € | |
Organisme | 100.00 € | |
Compte produit | 200.00 € |
Au final, les écritures comptables générées devraient être les suivantes s'il y a gestion de la TVA (exemple avec une TVA à 20%) :
Compte | Débit | Crédit |
---|---|---|
Utilisateur | 100.00 € | |
Organisme | 100.00 € | |
Compte produit | 160.00 € | |
TVA collectée (445710) | 40.00 € |
Fonctionnement des variables associées aux formules de tarification
Voici comment procèder pour configurer la notion de variable-formule dans le gestionnaire de tarification :
- Aller dans Ventes > Tarification des heures ou Ventes > Tarification des produits selon ce qu'il faut tarifier pour obtenir le tableau qui liste toutes les règles de tarification.
- Choisir une des règles. Par exemple, la première en haut de la liste et éditer.
- Dans le champ Nom de variable associé à la formule, mettre "XYZ" et valider le formulaire.
- Choisir une autre règle. En particulier, une règle qui va se déclencher avec la première règle lors de la saisie d'une fermeture de vol ou d'une vente de produit puis éditer
- Dans le champ Nom de variable associé à la formule, laisser cela vide. Dans le champ formule, l'éditer pour rajouter la variable associée à la première formule.
- Par exemple, avant on a : $a/200
- Après, on aura : $a/200+@XYZ
- L'utilisation d'une variable associée à une formule se fait en le précédant d'un @.
- Cocher Formule seulement si la règle ne doit pas génèrer des entrées comptables. Cela est pratique pour créer des valeurs de variable-formule intermédiaire.
- Dans le cas d'une règle de tarification des heures, associer la règle à un champ additionnel de catégorie Entrée comptable ou à aucun champ.
- Tester une saisie d'une fermeture de vol ou d'une vente de produit.
Voici comment cela se procède techniquement du côté de l'application pour tarifier :
- Recherche de toutes les règles de tarification dont les critères correspondent pour la saisie et qui sont applicables à celle-ci. Par exemple, deux règles sont trouvées.
- Récupération de la première règle pour analyser la formule de tarification. Visualisation qu'une variable (@XYZ) est associée à la formule de la règle alors lancement du calcul de la formule de tarification qui donnera 66,50. Application d'un arrondi sur le nombre de chiffre après la virgule en fonction de la comptabilité du compte impacté. Ensuite, stockage en mémoire que la variable @XYZ vaut 66,50.
- Récupération de la seconde règle pour analyser la formule de tarification. Visualisation qu'il n'existe pas de variable associée à la formule.
- Vu que la variable @XYZ a été trouvé dans la formule, récupération de sa valeur qui a été mise en mémoire puis remplacement de @XYZ par cette valeur, ici 66,50 même si les domaines d'application de la première règle de tarification diffèrent de la seconde.
- Ensuite, lancement du calcul de la formule de tarification qui donnera 100+66,50. Application d'un arrondi sur le nombre de chiffre après la virgule en fonction de la comptabilité du compte impacté.
- Dans le cas où dans la première règle, il n'y avait pas de variable associé à la formule. Au niveau de la seconde règle, la variable @XYZ serait remplacée par 0 car elle n'était pas stockée en mémoire.
- Dans le cas où une règle de tarification a été associée à un champ additionnel :
- Le champ additionnel prendra comme valeur le résultat de la formule.
- Si plusieurs formules ont été appliquées pour le même champ additionnel alors c'est la dernière formules qui sera prise en compte.
- Lors de la génération des entrées comptables par le moteur, les champs additionnels vont être associés à ces entrées comptables.
Exemple d'application et de non-application pour la tarification des heures
Voici un exemple de liste de règles de tarification :
Formule | Variable | Nom de la règle | Ressources concernées | Types de vol concernés | Compte à débiter | Compte à créditer |
---|---|---|---|---|---|---|
50 | X | Règle 1 | Ressource F-GAX | Local | Pilote | Ressource F-GAX |
@X+100 | Règle 2 | Ressource F-GAX | Instruction | Pilote | Ressource F-GAX | |
@X+150 | Règle 3 | Ressource F-TYH | Local | Pilote | Ressource F-TYH |
Saisie de vol avec comme types "Local" + "Instruction" et ressource "Ressource F-GAX"
Dans cet exemple, les règles 1 et 2 s'appliquent.
Au niveau du calcul du coût de vol, cela va procéder ainsi :
- Récupération de la règle 1, la formule donne 50
- Le compte "Pilote" est débité de 50 puis le compte "Ressource F-GAX" est crédité de 50 conformément à la règle 1
- Stockage en mémoire de 50 dans la variable X
- Récupération de la règle 2, la formule va donner X+100 soit 50+100
- Le compte "Pilote" est débité de 150 puis le compte "Ressource F-GAX" est crédité de 150 conformément à la règle 2
Saisie de vol avec comme type "Instruction" et ressource "Ressource F-GAX"
Dans cet exemple, seule la règle 2 s'applique.
Au niveau du calcul du coût de vol, cela va procéder ainsi :
- Récupération de la règle 2, la formule va donner donner X+100 soit 0+100 vu qu'il n'y a pas eu de stockage en mémoire de la variable X et que la règle 1 n'est pas applicable
- Le compte "Pilote" est débité de 100 puis le compte "Ressource F-GAX" est crédité de 100 conformément à la règle 2
Saisie de vol avec comme type "Instruction" et ressource "Ressource F-TYH"
Dans cet exemple, seule la règle 3 s'applique.
Au niveau du calcul du coût de vol, cela va procéder ainsi :
- Récupération de la règle 3, la formule va donner donner X+150 soit 0+150 vu qu'il n'y a pas eu de stockage en mémoire de la variable X
- Le compte "Pilote" est débité de 150 puis le compte "Ressource F-TYH" est crédité de 150 conformément à la règle 3
Exemple d'application et de non-application pour la tarification des produits
Voici un exemple de liste de règles de tarification :
Formule | Variable | Nom de la règle | Produits concernés | Compte à débiter | Compte à créditer |
---|---|---|---|---|---|
50 | X | Règle 1 | Bouquin | Principal | Boutique diverse |
@X+100 | Règle 2 | Bouquin Porte-clé |
Principal | Boutique diverse | |
@X+150 | Règle 3 | Carte | Principal | Boutique vol |
Saisie d'une vente de produit "Bouquin"
Dans cet exemple, les règles 1 et 2 s'appliquent.
Au niveau du calcul du coût de la vente, cela va procéder ainsi :
- Récupération de la règle 1, la formule donne 50
- Le compte "Principal" est débité de 50 puis le compte "Boutique diverse" est crédité de 50 conformément à la règle 1
- Stockage en mémoire 50 dans la variable X
- Récupération la règle 2, la formule va donner X+100 soit 50+100
- Le compte "Principal" est débité de 150 puis le compte "Boutique diverse" est crédité de 150 conformément à la règle 2
Saisie d'une vente de produit "Porte-clé"
Dans cet exemple, seule la règle 2 s'applique.
Au niveau du calcul du coût de la vente, cela va procéder ainsi :
- Récupération de la règle 2, la formule va donner donner X+100 soit 0+100 vu qu'il n'y a pas eu de stockage en mémoire de la variable X et que la règle 1 n'est pas applicable
- Le compte "Principal" est débité de 100 puis le compte "Boutique diverse" est crédité de 100 conformément à la règle 2
Saisie d'une vente de produit "Carte"
Dans cet exemple, seule la règle 3 s'applique.
Au niveau du calcul du coût de la vente, cela va procéder ainsi :
- Récupération de la règle 3, la formule va donner donner X+150 soit 0+150 vu qu'il n'y a pas eu de stockage en mémoire de la variable X
- Le compte "Principal" est débité de 150 puis le compte "Boutique vol" est crédité de 150 conformément à la règle 3
Mise en place de la facturation client
Sur OpenFlyers, il est possible de permettre que la saisie d'une vente de produit ou d'un vol puisse générer une ou des factures client. Pour permettre cela, éditer les règles de tarification.
Remplir les différents champs pour les formules :
- Quantité / taux
- Prix unitaire hors-taxe / TVA
Deux champs Groupe de facturation sont présents : l'un pour l'écriture de débit et l'autre pour le crédit. Y Associer un groupe de facturation permet que l'écriture générée par la règle soit incluse en tant qu'entrée de facture.
Les choix possibles sont :
- Non inclus dans une facture pour que l'écriture ne soit pas incluse dans la facture client.
- X : Un nombre indiquant dans quelle facture client l'écriture va être incluse.
Mettre en place une seule facture client pour la saisie
- Editer les règles de tarification applicables qui doivent figurer dans la facture client
- Y affecter le même groupe de facturation à ces règles. Par exemple 1.
Mettre en place plusieurs factures client pour la saisie
- Editer les règles de tarification applicables qui doivent figurer dans la première facture client.
- Y affecter un numéro de facturation à des règles. Par exemple 1.
- Editer les règles de tarification applicables qui doivent figurer dans la second facture client.
- Y affecter un groupe de facturation à des règles autre que 1. Par exemple 2.
- Editer les règles de tarification applicables qui doivent figurer dans la troisième facture client.
- Y affecter un groupe de facturation à des règles autre que 1 et 2. Par exemple 3.
- Répéter ce processus pour chacune des différentes factures à créer.
Facturation périodique
Fonctionnement de la facturation périodique
La facturation périodique se déclenche tous les jours aux alentours de minuit, fuseau Europe/Paris. Elle procède ainsi :
- Récupération de toutes les tâches de facturation périodique ayant la règle "every ..."
- Analyse de la règle "every ..." pour vérifier si la tâche doit être exécutée ou non pour ce jour. Si exécution :
- Récupération de toutes les règles de tarification rattachées à la tâche exécutée
- Pour chaque règle trouvée :
- Analyse de la requête affectée à la règle pour initialiser des variables nécessaires pour la tarification
- Traduction de la règle et tarification
Mise en place de la facturation périodique
Ajout d'un produit pour la facturation périodique
- Aller dans Admin > Ventes > Produits
- Créer un produit :
- Nom : Facturation périodique
- Type de vente : Produit périodique
- Les autres champs : A paramétrer selon les besoins
Ajout d'une tâche de facturation périodique
- Aller dans Admin > Ventes > Tarification des heures > Facturation périodique
- Ajouter une nouvelle ligne
- La colonne Evènement permet de définir quand va être lancé la tâche. Mettre l'un de ces textes à personnaliser :
- Pour une tâche lancée quotidiennement : every(* * *)
- Pour une tâche lancée tous les 1er février : every(1 2 *)
- Pour une tâche lancée tous les 1er d'un mois : every(1 X *). Remplacer "X" par le numéro du mois
Ajout de règles de tarification pour la tâche de facturation
- Ajouter une règle de tarification des heures de vol
- Dans le champ Produit, sélectionner le produit périodique créé.
- Dans le champ Tâche, choisir la tâche de facturation périodique qui déclenchera la règle de tarification. Il n'est pas possible de sélectionner la tâche "Close flight" à une règle de tarification affectée à un produit périodique.
- Dans le champ Requête, ajouter une requête SQL qui va permettre d'obtenir la liste des éléments à facturer.
Requête SQL de facturation périodique
Les requêtes SQL permettent de définir la liste d'éléments sur lesquels les règles de tarification périodique devront s'appliquer.
Les requêtes doivent être de type SELECT et le nom de chaque colonne doit être unique. Il est possible d'aliaser ces colonnes à un nom de variable.
Le résultat retourné doit être le suivant, peu importe l'ordre :
Donnée attendue | Présence obligatoire | Variable affectée | Valeur par défaut |
---|---|---|---|
Id de la personne en première place | OUI | %PILOT | |
Id de la personne en seconde place | NON | %PILOT2 | 0 |
Données métier : Nombre de jour entier d'une réservation | NON | %BOOKING_FULL_DAYS | 0 |
Données métier : Id de la réservation. Lorsque l'id est un nombre supérieur à zéro, un traitement spécifique est réalisé | NON | %BOOKING | |
Données métier | NON | Consulter la liste des variables |
Exemple de requête pour facturer les utilisateurs ayant une réservation au jour :
SELECT person_id AS '%PILOT', instructor_id AS '%PILOT2', id AS '%BOOKING' FROM booking WHERE DATE(start_date) = UTC_DATE()
Exemple de requête pour facturer les utilisateurs :
SELECT id AS '%PILOT' FROM person WHERE activated=1
Traitement spécifique de la facturation périodique
La présence de la variable %BOOKING dans la requête SQL d'une règle déclenche un traitement supplémentaire qui rattache les écritures générées aux réservations afin de :
- Facturer les réservations qui n'ont pas été déjà facturées
- Facturer le surplus pour les réservations qui ont été modifiées pour rallonger la durée de réservation