Facturation des clients: Difference between revisions
imported>Jcheng |
imported>Claratte |
||
Line 246: | Line 246: | ||
==Mise en place de la facturation périodique== | ==Mise en place de la facturation périodique== | ||
Il est possible d'effectuer une facturation périodique. La facturation s'effectue au mieux tous les jours. | |||
Il est possible d'effectuer une facturation périodique. La facturation s'effectue tous les jours. | |||
===Mise en place des règles de tarification pour la tâche de facturation=== | ===Mise en place des règles de tarification pour la tâche de facturation=== | ||
Line 255: | Line 254: | ||
[[Fichier:FormulaireTarificationFacturationPeriodique.png]] | [[Fichier:FormulaireTarificationFacturationPeriodique.png]] | ||
* Dans le champ '''Tâche''', choisir la tâche de facturation périodique qui ira utiliser la règle de tarification | * Dans le champ '''Tâche''', choisir la [[#Mise_en_place_d.27une_t.C3.A2che_de_facturation|tâche de facturation périodique]] qui ira utiliser la règle de tarification | ||
* Dans le champ '''Requête''', ajouter une requête SQL qui va désigner sur quoi on désire faire la facture | * Dans le champ '''Requête''', ajouter une requête SQL qui va désigner sur quoi on désire faire la facture | ||
====Requête SQL de facturation périodique==== | ====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. | |||
Le résultat retourné doit être le suivant et dans l'ordre indiqué : | |||
{| class="wikitable centre" | |||
!Donnée attendue!!Variable affectée | |||
|- | |||
|Id de la personne en première place||%PILOT | |||
|- | |||
|Id de la personne en seconde place. 0 si ce n'est pas géré||%PILOT2 | |||
|- | |||
|Numéro de réservation ou 0||%BOOKING | |||
|- | |||
|Nombre de jour entier d'une réservation ou 0||%BOOKING_FULL_DAYS | |||
|- | |||
|Données métier||%BUSINESS_DATA1, %BUSINESS_DATA2, etc. | |||
|} | |||
Exemple de requête pour facturer les utilisateurs ayant une réservation au jour : | Exemple de requête pour facturer les utilisateurs ayant une réservation au jour : | ||
Line 275: | Line 286: | ||
<sql>SELECT id AS 'PILOT1', 0 AS 'PILOT2', 0 AS 'BOOKING', 0 AS 'BOOKING_FULL_DAYS', '' AS 'BUSINESS_DATA1' | <sql>SELECT id AS 'PILOT1', 0 AS 'PILOT2', 0 AS 'BOOKING', 0 AS 'BOOKING_FULL_DAYS', '' AS 'BUSINESS_DATA1' | ||
FROM person | FROM person | ||
WHERE activated=1 | WHERE activated=1</sql> | ||
===Mise en place d'une tâche de facturation=== | ===Mise en place d'une tâche de facturation=== | ||
* Aller dans | * Aller dans '''Admin > Ventes > Tarification des heures > Facturation périodique''' | ||
[[Fichier:InterfaceFacturationPeriodique.png]] | [[Fichier:InterfaceFacturationPeriodique.png]] |
Revision as of 11:32, 29 December 2014
Présentation
L'objet de cette page est de présenter les points généraux de la facturation des clients dans la version 4 d'OpenFlyers.
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 4 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
- 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 | Aéronef F-GAX | Local | Pilote | Aéronef F-GAX |
@X+100 | Règle 2 | Aéronef F-GAX | Instruction | Pilote | Aéronef F-GAX | |
@X+150 | Règle 3 | Aéronef F-TYH | Local | Pilote | Aéronef F-TYH |
Saisie de vol avec comme types "Local" + "Instruction" et ressource "Aéronef 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 "Aéronef 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 "Aéronef F-GAX" est crédité de 150 conformément à la règle 2
Saisie de vol avec comme type "Instruction" et ressource "Aéronef 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 "Aéronef F-GAX" est crédité de 100 conformément à la règle 2
Saisie de vol avec comme type "Instruction" et ressource "Aéronef 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 "Aéronef 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.
Mise en place de la facturation périodique
Il est possible d'effectuer une facturation périodique. La facturation s'effectue au mieux tous les jours.
Mise en place des règles de tarification pour la tâche de facturation
- Editer une règle de tarification des heures de vol
Fichier:FormulaireTarificationFacturationPeriodique.png
- Dans le champ Tâche, choisir la tâche de facturation périodique qui ira utiliser la règle de tarification
- Dans le champ Requête, ajouter une requête SQL qui va désigner sur quoi on désire faire la facture
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.
Le résultat retourné doit être le suivant et dans l'ordre indiqué :
Donnée attendue | Variable affectée |
---|---|
Id de la personne en première place | %PILOT |
Id de la personne en seconde place. 0 si ce n'est pas géré | %PILOT2 |
Numéro de réservation ou 0 | %BOOKING |
Nombre de jour entier d'une réservation ou 0 | %BOOKING_FULL_DAYS |
Données métier | %BUSINESS_DATA1, %BUSINESS_DATA2, etc. |
Exemple de requête pour facturer les utilisateurs ayant une réservation au jour :
<sql>SELECT person_id AS 'PILOT1', instructor_id AS 'PILOT2', id AS 'BOOKING', 0 AS 'BOOKING_FULL_DAYS', AS 'BUSINESS_DATA1'
FROM booking
WHERE DATE(start_date) = UTC_DATE()</sql>
Exemple de requête pour facturer les utilisateurs : <sql>SELECT id AS 'PILOT1', 0 AS 'PILOT2', 0 AS 'BOOKING', 0 AS 'BOOKING_FULL_DAYS', AS 'BUSINESS_DATA1' FROM person WHERE activated=1</sql>
Mise en place d'une tâche de facturation
- Aller dans Admin > Ventes > Tarification des heures > Facturation périodique
Fichier:InterfaceFacturationPeriodique.png
- 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 :
- 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