Facture électronique

Product :4D - 4D Server
OS : Windows

Bonjour,

Quelqu’un a t’il déjà signé un PDF avec l’outil 4D?

Nous sommes de plus en plus confrontés à des demandes de nos clients qui souhaitent faire des factures électroniques. Pour la mise en place de la création d’un PDF, 4D nous donne les outils mais pas pour la signature du PDF ( ou pas trouvée )

Si vous avez été confrontés à cette problématique, comment l’avez-vous résolue?

La société 4D pense-t-elle nous mettre à disposition des outils et commandes 4D pour réaliser cela?

par avance, je vous remercie de votre réponse car la demande de nos clients devient de plus en plus urgente :-?

Voici ce qui a été réalisé par 4D concernant la Loi anti-fraude à la TVA.

Dans le processus, il y a les étapes de signatures électroniques de documents (pas forcément pdf).
Voir les codes sources de 4D-openss et 4D-logs.l

Cordialement

Dominique Delahaye

Communication adjointe :

Bonjour,

Pour faire suite à nos investigations sur la mise en conformité de vos applications vis à vis de la Loi anti fraude à la TVA,
nous avons mis à votre disposition une serveur ftp où vous trouverez des briques 4D répondant en partie aux exigences de cette Loi.

Ces briques sont disponibles « en l’état » en « open source », interprété et compilable.

Nous n’avons pas encore terminé nos recherches car nous explorons plusieurs pistes et nous vous tiendrons informé au plus vite.

Voici les accès du FTP :
URL : https://ftp-support.4d.fr/
Compte : Loi_TVA
Mot de passe : 7gYl8Ig

Le workflow peut se résumer comme suit :

Chainage Enregistrements
Une brique indépendante de gestion de chaînage des enregistrements disponibles sur le ftp dans le répertoire : recordChain sample

Vous trouverez dans la base exemple « Rec Chaining (v16) » la technique à utiliser sur le chaînage des enregistrements en SHA1 et la vérification du chaînage.
Hachage cryptologique

Les différentes recommandations et exigences concernant le respect de l’esprit de la Loi déconseillent l’utilisation du MD5 et SHA1 qui sont les seuls disponibles pour le moment dans 4D. L’utilisation d’un hash SHA2 (256 ou 512) est possible avec le plugin 4D ou le source est disponible ici :
https://github.com/miyako/4d-plugin-oauth

Un exemple d’utilisation est disponible dans le composant « 4D-openssl » dans la méthode openssl_integrity_check ( lignes : 76, 80)
ex : $hashValue:=SHA256 ($bin;Crypto HEX)

Journal d’événements techniques
Une brique de gestion des logs pour gérer les journaux d’événements techniques disponibles sur le ftp dans le répertoire : 4D-logs

Composant : 4D-logs (v14R5)
Permet de générer des logs journaliers dans un sous-repertoire de votre choix dans le répertoire « logs » situé au même niveau que la base de données .4DD.
Liste des commandes partagées :

chemin de votre répertoire de logs <- logFolderPath (nom de votre répertoire de logs : texte) : texte

chemin du fichier de log courant pour votre répertoire <- logFilePath (nom de votre répertoire de logs : texte) : texte

logWrite ( nom de votre répertoire de logs : texte ; texte à placer dans votre log )

Notes : ces méthodes sont toutes exécutées sur le serveur.

Voir son utilisation dans le composant « 4D-openssl » : répertoire « Logs » dans la zone « Démarrage » de l’explorateur 4D.

Signature Electronique
Une brique d’utilisation d’openssl sur Windows 32/64 bits pour gérer la signature vérification, manipulation des certificats disponibles sur le ftp dans le répertoire : 4D-openssl.

 Composant : 4D-openssl (v14R5 – Windows 32/64 *)
Note : il faut placer le composant 4D-logs si vous voulez voir les lois de ce composant qui se situeront dans dossier « openssl »
Ce composant permet sur Windows d'utiliser openssl qui n'est pas, contrairement à MacOS, installé par défaut.
Pour une utilisation sur MacOS vous pouvez l'adresser directement par LANCER PROCESS EXTERNE sans rechercher le bon chemin 32bits ou 64 bits.

Création de certificat auto-signé pour vos tests voir la méthode makeCertificat
Pour signer vos documents voir l’exemple dans la méthode _test

Liste des commandes partagées :

chemin du fichier de la signature « .sig » <- signDocument ( chemin du document à signer : text { ; algorithme de hachage [ « sha256 » par défaut ; « sha512 » ; ….] : texte ) : texte

succes <- verifyDocument ( chemin du document à vérifier : text ) : booléen
La signature du document « .sig » doit se trouver au même endroit que le document à vérifier. Ceci n’est pas une obligation, on peut modifier ce chemin en le passant en second paramètre , mais cela est à faire.

Notes : ces méthodes sont toutes exécutées sur le serveur.

Nous vous invitons aussi à parcourir la méthode documentation très mal nommée mais qui contient une liste de liens et ou informations qui nous ont permis de construire ce composant.

Nous restons à votre disposition pour l’utilisation des ressources que nous mettons à votre disposition.

Cordialement

Département : 4D-SERVICES

Je crois que Paul Kuhn propose une solution qui gère ça.

(vas-y Paul, fait ta pub sans être désolé, c’est moi qui ait commencé) :mrgreen:

as a study case, I posted this today (no timestamp, no verification, just signing)

https://github.com/miyako/4d-plugin-sign-pdf-versy

but a professional electronic paper trail would require buying a certificate from a trusted source,
paying for a timestamp from a trusted source (that stores it for 10 years or more), etc.

maybe a PHP solution would work?

https://tcpdf.org


it is one thing to sign for internal/personal purposes.
a free, in-house solution, even if technically robust,
may not pass as legal compliance.
think of it like an audit.

the best way probably is to sign up for a commercial web service.