Discussion :

[User]

Bonjour à tous,

J'espère vous donner dans cet article le maximum d'éléments pour vous permettre de créer avec Access votre propre logiciel de caisse.

Créer un logiciel de caisse avec Access

Objectif : apprendre à créer un logiciel de caisse enregistreuse avec Access.

Bonne lecture à tous,
Cordialement,
Denis

[tee_grandbois]

Bravo Denis !

[Malick]

Salut User,

Encore un excellent article

Merci encore

[ClaudeLELOUP]

Bonjour Denis,

Merci pour ce nouveau tutoriel.

J'ai essayé de l'adapter à ma machine… Mais où faut-il placer la table T_ParametreCaisse ? Je ne trouve pas la touche « F1 » !

[User]

Merci à tous pour vos commentaires

Claude

On ouvre le formulaire F_ParametreCaisse base sur la table T_ParametreCaisse, par le bouton Caisse sur le formulaire F_Opération.

Il faut que j'ajoute un paragraphe ou je décris tout ça.

Merci bien !

[MaPommeTao]

Excellent début, mais il manque l'essentiel pour que le système puisse au moins faire l'objet d'une certification.

Chaque ticket doit comporter une indication formé de 1 lettre + N° De certification en 4 chiffres + 5 caractères issus d'une clef RSA1028.

La clef du ticket N est calculée avec les données du ticket N et la clef du ticket N-1. Comme ça impossible de supprimer un ticket après l'avoir imprimée.

Le fisc exige en plus un programme qui permette de vérifier les clefs et un programme qui exporte en format FEC (Format Ecriture Comptable) toute sles données de facturation et d'encaissement. Il faut normalement sortir un ticket qui sert de "devis" au client et un deuxième ticket d'encaissement.

Tout ça est décrit dans un document de 122 pages écrit par INFOCERT qui a servi de conseil au fisc pour établir les règles de certification d'un logiciel.

La certification d'un logiciel de caisse coûte environ 30 000 €, 5 000 € pour les mises à jour suivantes. On peut néanmoins vendre un logiciel que l'on certifie soi-même, c'est une déclaration sur l'honneur qui est soumises à une amende de 45 000 € et 3 ans de prison en cas de mise en défaut par le fisc.

Je dis quand même bravo pour ce tutoriel, je commercialise moi-même un logiciel certifié par mes soins développé en FileMaker, le principe et les écrans sont similaires, il est plus complet que celui-ci avec la gestion des articles, des stocks, les ecritures comptables, les exports FEC et les statistiques.

[User]

Bonjour et merci pour ce complément d'information

...
La certification d'un logiciel de caisse coûte environ 30 000 €, 5 000 € pour les mises à jour suivantes. On peut néanmoins vendre un logiciel que l'on certifie soi-même, c'est une déclaration sur l'honneur qui est soumises à une amende de 45 000 € et 3 ans de prison en cas de mise en défaut par le fisc.

En effet, je ne pense pas que ce soit à moi de fournir les éléments ou le code pour obtenir cette certification au vu de l'amende.

Cdlt,

[MaPommeTao]

Bonjour et merci pour ce complément d'information
En effet, je ne pense pas que ce soit à moi de fournir les éléments ou le code pour obtenir cette certification au vu de l'amende.

Cdlt,

Il faut quand même que le fisc prouve que c'est avec le logiciel vendu et non une version "bricolée" ou en bricolant les bases que l'utilisateur a pu frauder.
On donne un certificat sur l'honneur mais on fait signer à l'utilisateur un formulaire dans lequel lui-même s'engage à ne pas modifier le logiciel qu'on lui vend ou a utiliser un système parallèlement au logiciel vendu.

Pour que le logiciel soit certifié et marqué conforme à la norme NF 525, il faut qu'il soit conforme à toutes les normes ISOxxxx concernant les logiciels :
- qualité,
- suivi des versions,
- documentations détaillées pour chaque version,
- jeux de tests,
- archivages,
- sauvegardes,
- impressions,
- FEC,
- clefs de cryptage,
- contenu des tables,
- utilisation de noms de rubriques conforme à la norme comptable
- etc ...
C'est un travail colossal que seul de gros éditeurs peuvent se permettre de faire. C'est la fin assurée des petits éditeurs.

[Paul TOTH]

Excellent début, mais il manque l'essentiel pour que le système puisse au moins faire l'objet d'une certification.

Chaque ticket doit comporter une indication formé de 1 lettre + N° De certification en 4 chiffres + 5 caractères issus d'une clef RSA1028.

La clef du ticket N est calculée avec les données du ticket N et la clef du ticket N-1. Comme ça impossible de supprimer un ticket après l'avoir imprimée.

Le fisc exige en plus un programme qui permette de vérifier les clefs et un programme qui exporte en format FEC (Format Ecriture Comptable) toute sles données de facturation et d'encaissement. Il faut normalement sortir un ticket qui sert de "devis" au client et un deuxième ticket d'encaissement.

peux-tu m'indiquer où se trouvent ces obligations ? et ne me répond pas dans la NF525 car celle-ci n'est pas une loi, c'est une interprétation d'INFOCERT dans le cadre de sa certification. Certification qui permet en effet d'être en règle avec le fisc, mais qui va à mon sens au delà des obligations légales.

Tout ça est décrit dans un document de 122 pages écrit par INFOCERT qui a servi de conseil au fisc pour établir les règles de certification d'un logiciel.

la NF525 est une marque, si la loi s'appuyait sur celle-ci, elle serait automatiquement publique et gratuite...ce qui est loin d'être le cas.

La certification d'un logiciel de caisse coûte environ 30 000 €, 5 000 € pour les mises à jour suivantes. On peut néanmoins vendre un logiciel que l'on certifie soi-même, c'est une déclaration sur l'honneur qui est soumises à une amende de 45 000 € et 3 ans de prison en cas de mise en défaut par le fisc.

45.000€ et 3 ans c'est pour la fabrication et usage de faux documents, mais encore faut-il que l'éditeur soit reconnu coupable.

Je dis quand même bravo pour ce tutoriel, je commercialise moi-même un logiciel certifié par mes soins développé en FileMaker, le principe et les écrans sont similaires, il est plus complet que celui-ci avec la gestion des articles, des stocks, les ecritures comptables, les exports FEC et les statistiques.

Tu certifies donc toi même le logiciel ?

[MaPommeTao]

Effectivement il s'agit bien d'une Norme et non d'une Loi, mais les préconisations de la norme créée par des représentants de la DGI, de l'AFNOR et d'INFOCERT servent de bases à la DGI pour accepter qu'un logiciel soit certifié, même s'il n'y a aucune loi aussi détaillée sur ce sujet.

La norme éditée par l'AFNOR permet simplement de définir les dispositifs à mettre en oeuvre pour garantir à l'utilisateur que l'objet à subi un certain nombre de vérification et de procédés de fabrication qui aboutissent à respecter les directives des bulletins et articles du code de la DGI en ce qui concerne ce genre de sujets . INFOCERT vérifie et contrôle que les éléments décrits dans la norme en question ont bien été respectés. AFNOR édite et garantie la norme qui a alors valeur de modèle pour une expertise en cas de litige et le fisc l'utilisera dans ce cadre.

Ce n'est ni plus ni moins qu'un manuel de savoir faire que chacun devrait respecter, mais c'est un doux rêve, comme l'absence de fraude à la TVA.

Je n'ai pas le droit de diffuser le document car il fait l'objet d'une formation payante à l'AFNOR/INFOCERT (720 €), tout se vend. AFNOR vend certainement un document détaillant la norme NF525.

Je n'ai pas non plus le droit de mentionner cette norme NF525 dans les documents commerciaux ou d'utilisation, même pas une mention du genre : "suivant les directives de la norme NF525"

J'ai simplement suivi ce que décrit ce document et mis en place ce qu'il faut pour que cela soit au plus près des conseils donnés.

il y a quand même un certain nombre de dispositif que le fisc exige de trouver dans un logiciel certifié :
- respect total de la chronologie : respecté
- période de remise à zéro des compteurs : mensuel ou annuel ou suivant exercice
- clôture et verrouillage des opérations : après impression du ticket
- inaltérabilité des données : chaînage pr clef RSA et archivage sans calculs
- archivages des opérations : mensuels, trimestriels, annuels et par exercice,
- extrait sous forme de FEC pour le fisc : conforme à ceux décrits dans le document INFOCERT/AFNOR
- chaînage des notes par des clefs inviolables cryptées : conforme aux préconisations INFOCERT/AFNOR
- possibilité de contrôle du chaînage accessible par un auditeur du fisc : en place
- contenu minimal des tables de données concernant le ticket, la facture, le détail du ticket ou de la facture : respecté
- impression de deux tickets, l'un pour le paiement, l'autre pour l'encaissement : respecté
- audit de toutes les opérations et anomalies : ajout d'une piste d'audit
- interdiction d'utiliser le mode "Formation" (utilisé largement pour masquer des opérations puisqu'il n'enregistre aucune donnée) sans le consigner dans l'audit du logiciel : respecté.
Ces éléments figurent dans des textes de lois ou des bulletins du code de la DGI concernant les écritures comptables, les archivages de données, les extractions à destination du fisc, les logiciels, etc...

Mon logiciel essaye de répondre à toutes ces obligations. Il n'est pas possible, par exemple, de supprimer volontairement une note ou une ligne de note via le logiciel, le chaînage par clefs est présent et contrôlable par un auditeur externe, les FEC et archives sont conformes aux obligations décrites dans les bulletins de la DGI concernant les fichiers d'écritures comptables déjà utilisés par tous les logiciels de comptabilité.

C'est une certification et l'autorisation d'afficher la conformité à une norme qu'INFOCERT et l'AFNOR vendent très cher. De plus cette certification impose d'être aussi conforme à d'autres normes concernant le contenu, la qualité et le développement de logiciel de ce type.

Tu peux consulter sur le site d'INFOCERT la grille des tarifs pour obtenir la certification d'un logiciel et la redevance pour la Norme NF525.

Je certifie moi-même mon logiciel, je connais mes clients et je les mets dans le coup en leur faisant signer un engagement.

[Paul TOTH]

Bonjour,

- extrait sous forme de FEC pour le fisc : conforme à ceux décrits dans le document INFOCERT/AFNOR
- chaînage des notes par des clefs inviolables cryptées : conforme aux préconisations INFOCERT/AFNOR
- possibilité de contrôle du chaînage accessible par un auditeur du fisc : en place
- impression de deux tickets, l'un pour le paiement, l'autre pour l'encaissement : respecté
- interdiction d'utiliser le mode "Formation" (utilisé largement pour masquer des opérations puisqu'il n'enregistre aucune donnée) sans le consigner dans l'audit du logiciel : respecté.

pour moi ces points ne sont pas dans la loi (en tout cas pas pour un "Logiciel de caisse"), et le mode formation n'est pas interdit, il doit simplement être clairement identifié.

sinon à part INFOCERT le Laboratoire National de Métrologie et d'Essais (LNE) peut également certifier le logiciel, et ils proposent en ligne et gratuitement leur documentation et notamment leur référenciel qui pointe chaque obligation légale.

[MaPommeTao]

Je n'ai pas dit que le mode Formation était interdit, c'est ce qu'on faisait avec qui est interdit. Il n'y aura plus de question à se poser puisque le passage en mode formation et les opérations faites dans ce cadre seront marquées d'une façon spéciale et auditées. Ce n'était pas le cas pour la quais totalité des logiciels de caisse actuels.

Le LNE préconise à peu près les mêmes choses que INFOCERT, il a l'avantage de le distribuer gratuitement. Dans son document, il est bien précisé les textes de lois et articles et BOI qui imposent ces dispositifs.
Toutes les méthodes de test décrites sont celles que le fisc pourra exécuter ou faire exécuter en cas de doute. Ayant rencontré déjà par deux fois des contrôleurs et les informaticiens qui les épaulent dans le cadre de l'assistance à mes clients, je vous prie de croire que ce ne sont pas des enfants de choeur, ils connaissent très bien la musique.

N'oubliez pas que certains contrôleurs sont d'anciens restaurateurs ou d'anciens commerçants.

[Paul TOTH]

Voilà qui indique clairement que cette loi est techniquement flou

18. Existe-t-il un référentiel officiel de mise en conformité des logiciels et systèmes de caisse ?
Éléments de réponse :
La loi instaure une obligation de résultat concernant la conformité des logiciels (respect des quatre
conditions de la loi : inaltérabilité, sécurisation, conservation, archivage) et non de moyen : elle ne
définit pas de cahier des charges, ni de solution technique, contrairement à d'autres dispositifs fiscaux.
L'élaboration de référentiels est donc du ressort des seuls acteurs privés

https://www.economie.gouv.fr/files/f..._de_caisse.pdf

on notera également

19. Pour respecter la condition d’inaltérabilité, l'intégrité des données enregistrées doit être garantie
dans le temps par tout procédé technique fiable. Des procédés autres que le scellement et le chaînage
pourront être proposés par les éditeurs. Comment apprécier la garantie d’inaltérabilité exigée ?
Éléments de réponse :
L'administration fiscale n'impose aucune solution technique (empreinte électronique, chaînage des
opérations…), dès lors qu'aucune norme fiscale a été prévue par le législateur.
Concernant les systèmes de caisse, la garantie d'inaltérabilité peut être obtenue par plusieurs
techniques permettant d'une part d'empêcher l'accès de l'utilisateur à des fonctionnalités de
modification des données validées et d’autre part de détecter tout accès/modification des données de
règlement. Toute modification ou correction doit être détectable.
Le certificat est associé à la capacité de pouvoir démontrer que les données de règlement n'ont pas été
modifiées depuis leur enregistrement initial et doit fournir un système de preuve en ce sens.

ainsi que

35. Les archives doivent être lues aisément par l’administration en cas de contrôle : quels sont les
moyens considérés comme aisés par l’administration pour lire les données ? En cas de cryptage des
archives quels sont les outils de décryptage acceptés ?
Éléments de réponse :
Les archives doivent pouvoir être lues aisément par l'administration. Aucun format d'archive n'est
toutefois imposé. De la même manière, en cas de cryptage de l'archive, aucun format de cryptage n'est
imposé. Les archives seront dans ce cas considérées comme pouvant être aisément lues par
l'administration (les données numériques par exemple apparaissant en clair et non sous forme codée),
dès lors qu'en cas de contrôle, l'assujetti à la TVA concerné présentera à l'administration des archives
décryptées.
A titre d'exemple, les formats de fichiers de type TXT ou CSV peuvent être utilisés pour l'archivage
(cf. BOI-BIC-DECLA-30-10-20-40 § 550).

La NF525 c'est un bazooka par rapport aux exigences de la loi, et faire croire qu'elle est obligatoire est une arnaque.

[MaPommeTao]

Je suis d'accord de l'utilisation d'un bazooka par la norme mais elle donne de sacrées idées au fisc en ce qui concerne les quatre conditions de loi.

J'ai eu l'occasion de discuter en dehors du cadre professionnel avec deux inspectrices du fisc (on choisit pas sa famille et le métier de ses membres) à ce sujet. Elles m'ont assurés que l'une de leurs exigences étaient une extraction en format texte mais au format FEC qui est devenu un standard pour tout ce qui touche à la comptabilité. le fisc a pris l'habitude depuis quelques années de traiter les données avec ce format et exigera qu'il soit utilisé au maximum. Ils ne conçoivent plus un fichier texte en dehors de ce format. Ils ont les logiciels pour traiter les fichiers de ce genre et reconstituer les factures ou les notes d'un restaurant.
Même si la loi est floue comme souvent, elle leur laisse suffisamment de liberté pour choisir ce qui peut être le garant du respect des quatre principes édictés. Leur raisonnement est très bien constitué et n'est pas posé à la légère.

Après chaque éditeur fait comme il veut, mais pour être conforme à la Norme NF525, il faudra passer par les exigences de INFOCERT, pas celle du fisc. Ils ne prennent aucun risque chez INFOCERT, pas question que le fisc ait des doutes sur la norme.

[Paul TOTH]

alors oui, si tu es normalisé NF525 tu respectes la loi, mais le fisc peut demander ce qu'il veux, c'est la loi qui dit que fichier TXT suffit ils peuvent ne pas être content, c'est pareil....après ils ont des possibilités de te compliqué la vie - contrôle fiscal par exemple - mais ils ne peuvent pas t'imposer des choses qui ne sont pas dans la loi, et ce n'est pas une interprétation de ma part, c'est le gouvernement lui-même qui le précise.

EDIT: en même temps je viens de regarder ce qu'est un FEC...c'est un fichier texte avec des colonnes normalisées qui ne sont pas très éloignées des obligations légale...du coup ce n'est pas un très gros effort

[MaPommeTao]

Oui, le FEC n'est pas un gros effort, déjà le fournir est faire preuve de bonne volonté.
Dans les autres choses que je jugerais nécessaire :
- supprimer tous les dispositifs qui permettent de modifier ou supprimer des opérations,
- utiliser des processus de génération automatique des numéros de factures ou documents,
- mettre en place un processus d'audit qui permet de tracer les opérations (début, fin, pannes d'imprimante, passage en mode formation, plantage, archivage, purge)

C'est à mon avis le minimum pour satisfaire le fisc et éviter qu'ils mettent leur nez plus en profondeur. En général, ils poussent les contrôles fiscaux s'ils ont des soupçons, pas à priori. Donc pas la peine de leur donner des raisons de fouiller.

Ce que la loi a mis aussi en place, c'est la responsabilisation et la poursuite de l'éditeur du logiciel en cas de fraude. Reste de toute façon au fisc à prouver que l'éditeur est fautif ou complice.
Il y a eu un cas dans la région PACA avec des pharmaciens (47 officines), un éditeur, un logiciel de caisse et une clef USB (vendue par l'éditeur) qui permettait de trafiquer les opérations.
Plus un éditeur sera près de la norme, moins il sera susceptible d'être complice ou accusé de favoriser la fraude à la TVA.

Moi, je joue dans ce sens et j'évite de donner au fisc une occasion de venir fouiller dans mes affaires. Quand ils insistent, ils trouvent toujours un petit quelque chose. C'est leur raison d'être.

[Paul TOTH]

alors pour revenir sur le format FEC c'est un "format" très très simple...il peut être en texte brute ou en XML mais reste super simple dans son format...par contre je patauge un peu dans les notions comptables (colonnes CompteNum et CompteLib)...ça reste de la compta "Debit + Credit = 0" ça c'est facile, mais ça génère des tas de lignes au final dans une logique très particulière qui n'est d'ailleurs pas uniforme d'un comptable à l'autre si j'en crois les forums que j'ai parcouru sur la question.

sinon oui, la loi c'est "inaltérabilité, de sécurisation, de conservation et d'archivage des données" sans cahier des charges ni contraintes techniques spécifiques mais ça implique l'impossibilité de faire disparaître une opération.

[MaPommeTao]

alors pour revenir sur le format FEC c'est un "format" très très simple...il peut être en texte brute ou en XML mais reste super simple dans son format...par contre je patauge un peu dans les notions comptables (colonnes CompteNum et CompteLib)...ça reste de la compta "Debit + Credit = 0" ça c'est facile, mais ça génère des tas de lignes au final dans une logique très particulière qui n'est d'ailleurs pas uniforme d'un comptable à l'autre si j'en crois les forums que j'ai parcouru sur la question.

sinon oui, la loi c'est "inaltérabilité, de sécurisation, de conservation et d'archivage des données" sans cahier des charges ni contraintes techniques spécifiques mais ça implique l'impossibilité de faire disparaître une opération.

Oui, le format FEC est très simple, pas de virgule, pas de point, pas de slash, pas de séparateur. Tous les chiffres et toutes les dates sont dans des formats bien définis.

Si on regarde une extraction FEC d'une achat ou d'une vente issu d'un logiciel comptable, on génère au minimum 1 ligne et parfois jusqu'à 4 ou même plus. Soit la ligne indique toutes les infos de la transaction sans mentionner les comptes (TVA, Banque) qui sont implicites, soit elle détaille chaque opération sur chaque compte du plan comptable utilisé par la société. (Client, TVA, banque)
CompteNum correspond au numéro de compte du plan comptable, CompteLib à son libellé.
Si certains code sont bien connus, les codes pour les comptes clients et fournisseurs sont laissés au choix de l'utilisateur, seul le radical 411 ou 401 est obligatoire.
On peut pour un restau regrouper tous les clients sous un code unique, du genre 4110 0000, pour les fournisseurs on utilisera des codes 4010 0001 à 4010 0999 par exemple. Les autres comptes peuvent être globaux, genre 4456 xxxx pour la TVA payée, 4457 xxxx pour la TVA collectée.

[Paul TOTH]

Oui voila, on peut, on peut, on peut...du coup on sait pas ce qu'on doit faire

notamment, j'ai lu qu'on pouvait se passer du 401 quand la vente est directe, ce qui est le cas d'une caisse de restaurant, on crédite les 701 et 445 et on débite le 530.

vu que le 701 ne détaille pas les articles, je suppose qu'on peut faire une ligne 701 par ticket au lieu d'une ligne par article, et une ligne 445 par taux de TVA.

à priori je ne veux faire qu'un journal de caisse vu que je fais un logiciel de caisse et non un logiciel comptable, du coup je n'utilise pas le 512 mais le 580 ou le 511, voir les deux.

c'est le jeu du compte est bon en fait, tu as un résultat "Debit + Credit = 0" mais pleins de solutions pour y parvenir

[tijo2035]

Comment faire pour mettre en fonction le bouton TVA et mettre le taux que l'on veux?