Logiciel Pastèque/Misc/Loi anti-fraude à la TVA
Mise en conformité LF 2016
[modifier | modifier le wikicode]Documents de référence
[modifier | modifier le wikicode]- BOFIP : Bulletin officiel, contraintes minimales
- Infocert, label NF525 (non disponible), attestation du logiciel
- Label LNE, attestation du logiciel
Résumé des contraintes
[modifier | modifier le wikicode]Ce résumé concerne uniquement la mise en conformité au regard du BOFIP. Les cahiers des charges pour les attestations sont nettement plus lourds et précis.
Données concernées
[modifier | modifier le wikicode]Concrètement, il s'agit de toutes les opérations réalisées sur la caisse (constitution d'un ticket, réception des paiements) ainsi que toutes les sommes de contrôles associées.
Par ailleurs, la comptabilité ajoute dans le journal de caisse toute entrée ou sortie de caisse. S'ajoutent donc les mouvements et les contrôles à l'ouverture et à la clôture.
Inaltérabilité
[modifier | modifier le wikicode]Il en découle :
Et finalement :
Sécurisation
[modifier | modifier le wikicode]La sécurisation va de pair avec l'inaltérabilité. Elle consiste à vérifier que les données ne sont pas altérées.
Conservation
[modifier | modifier le wikicode]En plus du détail, il faut calculer des données cumulatives :
Ce sont les tickets Z quotidiens, plus un aggrégat mensuel et annuel (par exercice, au minimum annuelle). Ces données doivent être conservées pendant 6 ans.
Chaque ticket ajoute un champ cumul pour la période (taille supérieure). Les Z quotidiens conservent le cumul jusqu'à la fin du mois et mensuels jusqu'à la fin de l'exercice. La comparaison entre le cumul du dernier Z quotidien doit correspondre avec le mensuel, idem avec les mensuel et l'annuel.
Enfin comme Pastèque est en mode client/serveur, il faut assurer l'intégrité des remontées d'informations
Il n'est pas indiqué si les traces de remontées sont à conserver côté client ou côté serveur.
Archivage
[modifier | modifier le wikicode]Une fois l'archive créée, il est possible de purger les données de Pastèque. À minima de les sortir de la base de données utilisée pour l'alléger.
La lecture des archives doit être possible indépendamment de Pastèque.
Il faut ajouter un journal d'archivage.
Les archives doivent être enregistrées sur un support physique externe. Par exemple par l'envoi d'une clé USB avec le fichier chiffré via clé privée et checksum.
La purge ne concerne pas les agrégats qui doivent rester enregistrés. Seules les données ligne par ligne peuvent être supprimées définitivement avec copie sur support physique (mais les conserver reste plus simple et pas forcément très coûteux en terme d'espace).
Solutions apportées
[modifier | modifier le wikicode]<WRAP center round info 60%> Commande = sharedticket
Ticket = ticket clos (payé) </WRAP>
Bande de caisse
[modifier | modifier le wikicode]La bande de caisse enregistre toutes les opérations réalisées sur la caisse. Inaltérable, elle permet de contrôler que toutes les informations ont bien été enregistrées.
<WRAP center round important 60%> Ce truc peut vite devenir monstrueux avec le partage de commande et gestion de conflits en cas de connexion dégradée et non partage de verrous.
Une caisse autonome est facile à gérer. </WRAP>
Le problème vient du non partage des données en mode déconnecté et de la non séparation des fonctions commande et encaissement. C'est à dire qu'il est possible pour n'importe quel caisse d'être utilisé comme prise de commande et comme règlement de commande. Ce qui veut dire qu'il est impossible en mode déconnecté de savoir au moment de l'encaissement si la commande est complète.
- Cas simple : pas de partage de commande. La caisse qui ouvre la commande est celle qui l'encaisse. C'est le cas de la plupart des configurations (une seule caisse par point de vente).
- Cas gros restau : un seul point d'encaissement, plusieurs points de commande, en local. Dans ce cas il suffit de prévoir un reversement manuel d'un poste de prise de commande sur la caisse centrale en local (comme c'est fait avec le papier)
- Cas extrême : plusieurs points d'encaissement avec plusieurs points de commande. OSEF ?
On se contentera du modèle de caisse commande/encaissement unique pour commencer. On pourra rajouter des modules de prise de commande numériques dans la v9. Pour le cas extrême, il ne se présentera peut être jamais.
Contenu
[modifier | modifier le wikicode]- L'opération d'ouverture (permet d'ajouter un contrôle d'exhaustivité, début de bande)
- OPEN <caisse> <hostsequence>
- L'ouverture et selection d'une commande
- CORD <id> (create order)
- Le changement de commande (select)
- SORD <id> (select order)
- Tout ajout de ligne à une commande (y compris en quantité négative)
- ADD <order> <line> <ref> <lbl> <qty> <ht> <rate> <vat>
- L'identifiant de commande (order)
- Le numéro de ligne (line)
- Référence et intitulé (la référence fait office d'ID user-friendly, l'intitulé apparaît sur le ticket)
- Quantité, montant HT, taux TVA, montant TVA
- ADD <order> <line> <ref> <lbl> <qty> <ht> <rate> <vat>
- Toute modification d'une ligne à une commande (modification manuelle ou via remise, zone tarifaire)
- EDT <order> <line> <ref> <lbl> <qty> <ht> <discount> <htdisc> <rate> <vat>
- Tout ajout de paiement (et toute annulation), y compris le rendu monnaie (autre ligne)
- PORD <id> <mode> <amount>
- L'identifiant de ticket
- Mode de paiement
- Montant
- PORD <id> <mode> <amount>
- Toute assignation à un client (peut ajouter la ligne de remise globale)
- Tout changement de la zone tarifaire (ajoute les commandes d'update)
- Toute application de remise globale sur la commande
- DISC <id> <rate>
- Toute finalisation de commande (création d'un ticket)
- FORD <id> <caisse> <tktnum>
- L'identifiant de commande
- L'identifiant de ticket (caisse + numéro)
- FORD <id> <caisse> <tktnum>
- Toute impression d'un ticket (pour éviter la réutilisation du même ticket pour x clients et assurer que les tickets sont imprimés)
- PRT <caisse> <tktnum>
- Toute suppression de commande (si on peut le faire)
- DORD <id>
- Tout mouvement de caisse (optionnel mais facilite le contrôle de fin de session)
- IO <mode> <amount>
- Entrée, sortie, mode, montant
- L'opération de clôture (permet d'ajouter un contrôle d'exhaustivité, fin de bande)
- CLOSE
Plus généralement chaque fois que l'utilisateur appuie sur un bouton.
<WRAP center round important 60%> C'est un giga log qui permettrait même de rejouer les ventes en isolation complète d'une caisse et reconstituer l'intégralité du Z. Le format binaire permet de compresser le log au maximum. Il faut le conserver 6 ans. 32 octets de checksum minimum par opération. </WRAP>
Chaque ligne doit être datée. Pour assurer l'inaltérabilité, chaque enregistrement est numéroté et chaîné au suivant et au précédent. De cette manière, l'édition manuelle de la bande nécessite le recalcul complet de la bande et donc l'usage d'un programme externe. Pour plus de sécurité la bande peut être enregistrée au format binaire, ce qui implique d'étudier le format dans le code source pour la réalisation d'un programme d'édition. Le chiffrement par clé publique apporte plus de complexité sans pour autant ajouter de sécurité (la clé étant publique, la reconstitution de la bande suit le même procédé que pour le format binaire mais ajoute des difficultés à l'installation).
De plus, les données doivent être auto-suffisantes. Il n'y a donc pas de récupération de données externe par ID par exemple.
<WRAP center round help 60%> Si la bande enregistre toutes les modifications, ajout et suppressions, le ticket peut-il ne conserver que le résultat final (i.e. ne pas indiquer les lignes d'erreurs) ?
Réponse : non, ne prenons pas de risque </WRAP>
La bande de caisse est liée à la session (ouverture/clôture). Ces sessions étant numérotées, il est aisé de s'assurer que tout est remonté (pas de trou dans la suite des sessions de caisse). Ce checksum peut être utilisé pour le premier enregistrement de la prochaine bande histoire de chaîner tout de bout en bout.
<WRAP center round important 60%> Pour aller jusqu'au bout, il reste la possibilité de supprimer le cache en début de session. La bande peut donc ajouter un contrôle de continuité dans le cache (présence du précédent close) </WRAP>
Contrôle d'intégrité
[modifier | modifier le wikicode]Le contrôle d'intégrité des bandes s'effectue à plusieurs niveaux :
- Ligne par ligne : vérification de la continuité de la numérotation, vérification des checksum
- Intégrité de la bande : opération 1 = ouverture de caisse, dernière opération clôture de caisse.
- Intégralité des bandes : vérification de la continuité des hostsequence
<WRAP center round important 60%> Cas tordu : l'ouverture de la session sur un poste, abandon de ce poste puis reprise de la session sur une autre machine avec le même nom de caisse. La bande est coupée en deux. </WRAP>
Le contrôle d'intégrité des tickets Z s'effectue avec les bandes :
- Correspondance 1 à 1 entre une bande et un ticket Z (caisse et hostsequence)
- Correspondance du total par mode de paiement
- Correspondance du total HT et TVA par taux
Tickets et Agrégats
[modifier | modifier le wikicode]<WRAP center round info 60%> La notion d'archive dans le BOFIP fait référence à un document figé non éditable. Par exemple lors de la clôture d'une période comptable, celle-ci est archivée (non modifiable et datée définitivement).
La purge au sens du BOFIP concerne la suppression des données hors archive après intégration dans ces dernières. </WRAP>
Enregistrement des tickets
[modifier | modifier le wikicode]Chaque ticket a valeur de facture, il faut donc s'assurer qu'ils ne sont pas altérés ni modifiés.
L'enregistrement des tickets est double :
- Un enregistrement en bdd permet l'analyse informative performante (vente par produits, statistiques horaires etc). C'est l'enregistrement actuel, il ne constitue pas une archive et peut être purgé.
- Un enregistrement fiscal inaltérable pour archive et contrôle. C'est un nouvel enregistrement autonome inaltérable à ajouter. Les déclarations fiscales sont basées sur ces données. Il s'agit d'une archive, elle ne peut être purgée.
Comme pour les bandes de caisse, les archives sont numérotés (nom de caisse + numéro de ticket), avec checksum et chaînage. Le contenu peut être du plain texte au format json pour garantir l'évolution du schéma dans le temps et assurer une retro-compatibilité.
L'archive est intégrée au moment de la clôture de la période (soit la clôture de la session de caisse). La périodicité choisie est donc d'approximativement 1 jour ce qui est conforme avec le BOFIP (maximum 1 an).
<WRAP center round important 60%> Pour les réfractaires à la clôture quotidienne, il faudra s'y mettre pour conserver l'attestation. Article 170 du BOFIP.
Nuance : le cahier des charges de LNE indique cette obligation comme donner la possibilité à l'utilisateur de le faire quotidiennement. À sa charge de le faire. </WRAP>
Enregistrement des tickets Z et agrégats
[modifier | modifier le wikicode]Comme pour les tickets, les tickets Z font l'objet d'un enregistrement inaltérable. Il n'existe par contre pas de donnée dédiée actuellement. Les tickets Z sont directement archivés.
Le BOFIP n'indique pas si les cumuls sont à effectuer par caisse ou sur l'ensemble par période (quotidienne, mensuelle et par exercice).
Dans le doute, faisons les deux.
Chaque caisse donne un Z à la clôture. Si ce Z correspond vaguement à une journée, il est utilisé pour l'agrégat quotidien. Sinon une ou plusieurs coupures arbitraires doivent être effectuée.
L'agrégat quotidien regroupe chaque Z (ou portion ou concaténation de Z) et le total, plus le cumul du mois.
<WRAP center round info 60%> Exemple agrégat du 02/04 (avec un 01/04 à 50 de CA et 10 de TVA 20)
caisse 1 CA 100, TVA 20 100/20
caisse 2 CA 10, TVA 20 10/2
Total CA 110, TVA 20 110/22
Cumul CA 240, TVA 20 240/48 Grand total CA 54600, TVA 20 54600/10920 </WRAP>
L'agrégat mensuel calcule les données de ventes des caisses sur toute la période du mois. Si une session de caisse est largement à cheval entre deux mois, une coupure doit être réalisée.
L'agrégat mensuel doit correspondre à la somme des agrégats quotidiens, sinon on dira que les données ont été altérées entre deux.
Idem pour l'exercice.
<WRAP center round todo 60%> Selon LNE, le texte est à comprendre dans le sens laisser à l'utilisateur la possibilité de faire une clôture journalière et mensuelle. Pas forcément de faire les deux.
N'est toujours pas indiqué si la clôture est caisse par caisse ou globale </WRAP>
Purge
[modifier | modifier le wikicode]Les archives ne concernent que les données non archivées. C'est à dire les données tickets actuelles (TICKETS, TICKETLINES etc). Ne peuvent être purgées que les données qui ont fait l'objet d'une archive.
La suppression de ces données doit faire l'objet d'un enregistrement de purge. Une purge crée donc un document archivé listant tous les identifiants de tickets (caisse + numéro, mais aussi lignes et tout ça) purgés.
Notes en vrac
[modifier | modifier le wikicode]Suppression des fonctionnalités hors encaissement
[modifier | modifier le wikicode]BOFIP sur les documents justificatifs de comptabilité.
Les systèmes de gestion de stock, production, immobilisation, peuvent faire l'objet du contrôle. Histoire de ne pas s'embêter avec tout ça. Pastèque ne DOIT PAS être utilisé fiscalement pour tout autre usage que les déclarations de vente (CA, TVA).
Exit donc tout ce qui ne s'intègre pas dans un ticket, comme la gestion du stock.
Ces fonctionnalités doivent faire l'objet d'un logiciel annexe. Ça tombe bien les tables en bdd sont indépendantes des tables de ventes.
1)
BOFIP, article 50
2)
BOFIP, article 80
3)
BOFIP, article 90
4)
BOFIP, article 120
5)
BOFIP, article 140
6)
BOFIP, article 170
7)
BOFIP, article 200
8)
BOFIP, article 210
9)
BOFIP, article 220
10)
BOFIP, article 230
11)
BOFIP, article 240
12)
BOFIP, article 250