Execute News

Si vous êtes commerçant, vous le savez probablement (du moins je l'espère pour vous), à partir du 1er janvier 2018, vous devez avoir une caisse "certifiée".

Vous avez sans doute aussi entendu parlé de la NF525 pour faire certifier votre logiciel par la société AFNOR. Mais même s'il existe une certain confusion entre la Loi de Finances 2016 (LF2016) et le produit commercial NF525 celui-ci n'est en rien obligatoire.

Ce que dit la loi, c'est qu'au 1er janvier 2018, tout utilisateur d'un logiciel de caisse doit produire un certificat de conformité LF2016 de son logiciel sous peine d'une amande de 7.500€ - même si votre caisse est parfaitement carrée et sans la moindre fraude fiscale ! On voit de suite l'intérêt de la procédure...

Pour obtenir cette attestation il existe trois possibilités :

1) Faire une demande d'homologation NF525 auprès de la société AFNOR; cela implique de faire l'acquisition (500€) de la norme en question, d'adapter votre logiciel pour s'y conformer, et de faire valider votre logiciel par AFNOR, pour 1 an, et sous réserve de toute modification de celui-ci. Cette attestation - si vous l'obtenez - permet d'être conforme aux exigences de la LF2016.

2) Faire une demande d'homologation auprès du Laboratoire National de Métrologie et d'Essais (LNE) qui propose la même prestation, à la différence prêt que le cahier des charges est disponible en ligne, cela ne vous affranchit pas de payer l'homologation, mais au moins vous savez ce qui vous attends.

3) Seuls AFNOR et le LNE sont accrédités pour homologuer les logiciels, aucun autre prestataire ne peut le faire... sauf l'éditeur lui-même. En effet, la loi prévoit qu'un éditeur de logiciel de caisse puisse délivrer une attestation individuelle à ses clients pour attester que le logiciel respecte la LF2016.

Ok, mais de quoi est-il question ? j'ai entendu parler de signature électronique, de blockchain et de tas de choses mystérieuses qui m'inquiètent...n'est-il pas préférable de passer par AFNOR ou le LNE ?

En fait, la loi est extrêmement vague ! Il n'existe aucun cahier des charges ni aucune contrainte technique d'aucune sorte !

Ce qu'exige la loi c'est d'apporter des solutions aux 4 points suivants :

1- Inaltérabilité : les mouvements de la caisse ne doivent pas être modifiables ou supprimables (comme en compta), s'il y a une erreur, on fait un mouvement pour la corriger, mais on ne supprime pas l'erreur !

2- Sécurisation : le logiciel ne doit pas permettre la modification des données, on ne doit donc pas permettre (ou tout au moins détecter) toute modification dans la base de données par exemple.

3- Conservation : les données doivent être conservées dans le temps, 6 ans !

4- archivage : l'archivage consiste en réalité à figer les données à une date donnée...notez que sur un système inaltérable dont ont conserve les données 6 ans, cette notion me semble un peu douteuse...

Bref, pour avoir un logiciel conforme, il faut une attestation de l'éditeur selon laquelle il est conforme à ses exigences.

Notez que la notion "d'éditeur" et particulière, notamment dans le cadre d'un logiciel OpenSource, l'intégrateur - qui n'est pourtant pas le développeur mais celui qui met en oeuvre le logiciel et son paramétrage - devient l'éditeur dans le cadre de la LF2016.

Dernière remarque, si un commerçant a développé lui-même son propre logiciel de caisse, il ne peut s'auto-certifier QUE s'il a un code APE d'éditeur logiciel.

Je viens de découvrir un projet qui m'intéresse beaucoup. Je suis un inconditionnel du langage Pascal, mais avec l'offre mutualisée de OVH il est pratique d'héberger des sites web en PHP/MySQL...ce qui m'amène à faire du développement PHP, ce que je trouve parfois pénible je dois l'avouer.

J'ai essayé à plusieurs reprises de trouver un mode de fonctionnement agréable en PHP, comme avec Pho, mais rien n'y fait, je préfère toujours le Pascal et de façon générale les langages compilés...Un compilateur Pascal pour PHP, voilà qui mérite qu'on s'y intéresse : pas2php !

J'ai longtemps travaillé avec Delphi 6, bien après la sortie de Delphi XE et de ses successeurs.

Ce n'est que récemment que j'ai basculé la grand majorité de mes développements sur les dernières versions de Delphi, aussi quand j'ai écrit l'unité Execute.GDIPBitmap j'ai utilisé les dernières possibilités du langage.

Mais qu'à cela ne tienne, je viens de faire une version pour les anciennes version

Delphi supporte depuis plusieurs versions les formats JPEG et PNG, par contre en standard, il n'est pas possible de lire des images TIFF.

Qu'à cela ne tienne, on s'appuyant sur GDI+, l'unité Execute.GDIPBitmap ajoute une méthode GDIPLoadFromStream à la classe TBitmap.

uses
  Execute.GDIPBitmap;
var
  bitmap: TBitmap;
  stream: TFileStream;
begin
  bitmap := TBitmap.Create;
  stream := TFileStream.Create('SAMPLE.JPG', fmOpenRead or fmShareDenyNone);
  bitmap.GDIPLoadFromStream(stream):
  stream.Free;
end;

GDIPBitmap sur Github

Execute publie régulièrement des codes sources pour Delphi sur son repository Github !

https://github.com/tothpaul