QR-factures pour la Suisse

Salut Fred,

Sur la base de ton idée, je bidouille le code depuis un moment. Je suis arrivé à un résultat très satisfaisant en ajoutant deux bouts de code pour déformer le QR-Code Excel et le logo suisse afin qu'ils soient carrés à l'impression (avec recentrage de la croix) :

   ' Déformation de la forme afin que le QR-Code soit imprimé carré
    ActiveSheet.Shapes.Range(Array("myQRCode")).Select
    Selection.ShapeRange.Width = 145
    Selection.ShapeRange.LockAspectRatio = msoFalse ' Obligatoire, sinon le ratio 1/1 est rétabli par l'instruction ci-dessous.
    Selection.ShapeRange.Height = 163

Merci beaucoup pour ton aide.

Mon QR-code imprimé (et contrôlé officiellement) :

@yves

Cool

Bonne continuation

Fred

Même le redimensionnement, c'est beaucoup d'énergie pour pas rien car le QRCode est lu correctement en l'état. Ah la précision Suisse ...

Euhhhh.. je ne suis pas Suisse...

Fred

Salut Steelson,

Je t'ai indiqué que nous avons préparé l'envoi de 700 factures malgré des QR-Codes écrasés car ils fonctionnent malgré tout.

Maintenant, si ces 700 personnes ou couples tiquent en voyant mon QR-Codes bizarres, ça me gêne un peu. Comme la solution est simple - et ne demande que très peu d'énergie, contrairement à ton affirmation - je trouverais dommage de ne pas l'utiliser à l'avenir.

Est-ce vraiment une particularité seulement helvétique, l'envie de bien faire ?

Bonsoir à tous

Est-ce vraiment une particularité seulement helvétique, l'envie de bien faire ?

Perso... l'envie de bien faire... sinon je n'aurais pas cherché de solution...

Fred

Tu as raison, j'aime aussi ce qui est propre et bien fini. Je suis aussi marqué par mes années d'optimisation des coûts, des temps et des cycles en allant aussi à l'essentiel.

Pour le coup, je n'avais pas vu ta solution qui est génial ! https://forum.excel-pratique.com/excel/qr-factures-pour-la-suisse-105696/12#p913052 Donc tu as trouvé comment s'affranchir de ce carré têtu en tordant le cou à LockAspectRatio.

Je me disais aussi qu'avant cela, il fallait fusionner (grouper par ActiveSheet.Shapes.Range(_____________).Group ) l QRCode et la croix pour qu'ils soient solidaires et se remettent au carré ensemble. Mais cela signifie aussi dégrouper avant de recréer un nouveau QRCode, donc pas mal de gymnastique.

Dois-je de mon côté corriger le code ou in fine tu as tout ce qu'il te faut ?

Salut Steelson,

Merci pour ta réponse. Pour moi j'ai tout ce qu'il faut

D'ailleurs je pense que les déformations nécessaires ont à voir avec l'imprimante utilisée et que mon réglage actuel sera à modifier sur une autre imprimante.

Cordiales salutations.

Bonjour à tous..

je ne suis pas sur que la déformation soit liée à l'imprimante... car si je me rappel bien (car j'ai dormi entre temps... ) une impression papier directement depuis excel et une impression en pdf puis impression papier donne le même résultat. Je ne suis pas chez moi pour le moment je ferais un essai dans la soirée, pour confirmer ou infirmer ce que je viens de dire...

Fred

Lu par ci par là avec confirmation de la méthode d'Yvouille

https://stackoverrun.com/fr/q/8516093

https://forums.commentcamarche.net/forum/affich-27752012-format-d-image-change-lors-de-l-impression

Bonjour,

Bifrons a écrit :

Ceci dit, un gros problème avec le montant, swiss-qr-invoice voit 1949,5 alors que le format forcé de la cellule est # ###.00 comme exigé par leur norme et pire l'image générée sur leur simulateur = 19 495.00 !

effectivement, c'est un point que j'avais déjà rencontré ici https://forum.excel-pratique.com/excel/qr-factures-pour-la-suisse-105696/10#p909689

pour forcer la valeur en texte avec un point, essaie ceci dans D20 (avec un format standard)

=ENT(E20)&"."&DROITE("00"&(ENT(100*E20)-ENT(E20)*100);2)

en mettant la valeur dans E20

s'il veulent l'espace des milliers il faudra adapter.

Suite ...
Problème du montant résolu avec ta solution Steelson, top et merci, selon les infos soumises, le QR fait à l'impression PDF entre 40 et 44 mm
On résout un problème et 1 autre apparaît :( pas cool
Je n'avais pas testé les accents ou caractères spéciaux, et bien c'est fait et ça ne passe pas

Dans les cellules standards si on met un accent du style Société, la validation ne passe plus ! (par ex. Société Sàrl - M. Le Big Boss)
Msg d'erreur : Le QR-code doit être encodé en UTF-8 mais l'encodage suivant a été détecté : ISO-8859-1

- Nouvelle mise en page du fichier avec 1 colonne de saisies pour éviter les erreurs et différents formatages de cellules, on peut ainsi ajouter des lignes (mais pas de colonnes) en-dessus du BV (attention à adapter la macro pour les 2 cellules Montant (R59 actu) et DEBF – Prénom Nom (R62 actu)) et ainsi se créer sa propre facturation. Si impression en PDF (testé avec PDF Creator gratuit), en l'état, le BV sera imprimé en bas de page

- Si le champ montant n'est pas indiqué : au lancement de la macro, affichage des coins pour saisie manuelle après impression

- Si le champ Payable par (Nom et prénom) : idem ci-dessus, affichage des coins au lancement de la macro ...

Je joins mon fichier (sur base Steelson bien sûr), si ça peut aider. Il risque d'évoluer, raison pour laquelle j'ai ajouté un numéro de version

Hello

Bifrons a écrit :

On résout un problème et 1 autre apparaît :( pas cool
Je n'avais pas testé les accents ou caractères spéciaux, et bien c'est fait et ça ne passe pas

Dans les cellules standards si on met un accent du style Société, la validation ne passe plus ! (par ex. Société Sàrl - M. Le Big Boss)
Msg d'erreur : Le QR-code doit être encodé en UTF-8 mais l'encodage suivant a été détecté : ISO-8859-1

Il y a bien une fonction de transformation en utf-8 des données, et notamment des caractères diacritiques latins. On a déjà rencontré ce problème, mais cela passe chez SIX https://forum.excel-pratique.com/excel/qr-factures-pour-la-suisse-105696/10#p903862. Je persiste à penser qu'il y a un schmilblick dans leur application, non pas concernant les donnés elles-mêmes, mais concernant le déchiffrage du QRCode.

Bonjour à tous,

Je n'étais pas revenu sur le post depuis quelques jours.

J'ai constaté la même déformation du QRcode que cité plus haut. Le QRCode généré sur Excel est parfaitement carré, mais dans mon application je crée un PDF. Et là le QRCode est comme tassé sur lui-même, en affichage sur l'écran et aussi sur papier. Je génère le PDF en créant un fichier PDF à partir de Excel .

Je vais faire un test avec la solution proposée par Yvouille (merci à lui) et je reviendrai.

Meilleures salutations.

Cloburk

Hello ,

J'ai inséré le bout de code de Yvouille dans le Process de création du QRCode. Après quelques essais, j'ai fixé les deux valeurs:

.Width = 150 et .Heigth = 163.

Ceci me donne un QRCode légèrement déformé dans la feuille excel, mais parfaitement carré dans le pdf et de surcroît de 46 x 46 mm comme le demandent les normes au moment de l'impression depuis le PDF. Ceci me permettra de modifier en fonction de l'imprimante utilisée.

C'est juste top.

Merci encore à tous ceux qui contribuent à faire avancer le schmilblick.

Plus on en sait, plus on sait qu'on ne sait pas grand chose........

Cordialement.

Cloburk

Salut Steelson,

Je dois revenir à la charge avec mon problème.

PostFinance a refusé certains bulletins QR-Factures et, lorsque je ne suis renseigné pourquoi, on a avancé le fait que soit l'on a pas encodé à l'aide de UTF-8 ou alors qu'on aurait utilisé des signes non-admis (le passage en allemand dans la 3ème feuille du fichier ci-joint qui explique pourquoi ''Rue de la Tuilière 26'' n'a pas été accepté, le è étant ici remplacé par un point).

Ces arguments sont très étranges puisque a) une facture test a été payée personnellement à un guichet de PostFinance et a été acceptée malgré qu'elle contenant un accent (Route de la Gruyère) b) qu'une facture refusée une première fois a semble-t-il été acceptée une seconde fois (bien que je ne suis pas certain que notre membre a fait les deux tentatives absolument identiquement) et c) qu'il semble qu'aucun autre établissement financier n'a refusé de nos QR-Facture. A propos de a) et b), PostFinance m'a dit par oral qu'il se pourrait que tous les lecteurs qu'ils utilisent n'ont pas la même sévérité dans la manière de lire ces codes !!??

Dans sa lettre, PostFinance prétend également que les contrôles effectués sur le site SIX ne s'occupent pas de l'encodage en UTF-8 ou non et qu'ils vont demander à cette entreprise ''faitière'' de corriger cela (antépénultième et pénultième paragraphe de la première page de la lettre jointe).

De ton côté, que penses-tu de cela ? Est-ce que vraiment le passage de ton code qui s'occupe de cet encodage UTF-8 laisserait passer l'une ou l'autre chose ? Une autre piste ?

Amicalement.

Bonjour,

Quand tu lis le QRCode avec un smartphone, est-ce que tu vois le point ou est-ce que tu vois le caractère accentué ?

Par ailleurs, en amont de python, on peut voir aussi la codification (pas facile car tous les logiciels vont traduire automatiquement les caractères utf-8), mais voici une macro qui respecte les données

Il faudrait même aller plus loin et lire en hexadécimal pour en donner une preuve plus tangible ... soit avec https://sourceforge.net/projects/hexedit/, soit en ligne avec https://korben.info/editeur-hexadecimal-en-ligne.html (qui dit à juste titre, "Autant on peut se passer de Nutella, autant, se passer d'un éditeur hexadécimal est beaucoup plus difficile."). On voit bien sur cet exemple comment est écrit Hélène en hexadécimal dans un fichier test python : j'ai mis en rouge les caractères ascii "normaux" et en jaune sur 2 octets les caractères codés en utf-8 comme le é et le è

Le fin du fin serait qu'on puisse le faire en lisant le QRCode lui-même.

Je crains une querelle de spécialistes "non-spécialistes" entre informaticiens "pseudo-informaticiens" de SIX et Postfinance, relayée par des interfaces clientèle qui n'ont sans doute pas vraiment plus de compétence en la matière, bref des gens qui ne vont pas se comprendre et tous prétendre avoir la vérité, de quoi tourner en bourrique (expression française). Si en effet Postfinance commence par écrire à SIX pour changer de fusil d'épaule, on n'est pas sorti de l'auberge ... en espérant qu'ils ne confondent pas utf-8 et utf-16.

Le programme qu'on a élaboré contient bien un module de codification utf-8

UTF-8: encodage à largeur variable, rétrocompatible avec ASCII. Les caractères ASCII (U + 0000 à U + 007F) prennent 1 octet, les points de code U + 0080 à U + 07FF prennent 2 octets, les points de code U + 0800 à U + FFFF prennent 3 octets, les points de code U + 10000 à U + 10FFFF prendre 4 octets. Bon pour le texte anglais, pas si bon pour le texte asiatique.

UTF-16: encodage à largeur variable. Les points de code U + 0000 à U + FFFF prennent 2 octets, les points de code U + 10000 à U + 10FFFF prennent 4 octets. Mauvais pour le texte anglais, bon pour le texte asiatique.

UTF-32: encodage à largeur fixe. Tous les points de code prennent quatre octets. Un énorme cochon de mémoire, mais rapide à utiliser. Rarement utilisé.

...

UTF-8 est variable de 1 à 4 octets.

UTF-16 est variable de 2 ou 4 octets.

UTF-32 est fixé à 4 octets.

il n'est pas de moi, mais il est assez limpide et on retrouve la définition donnée ci-dessus ...

Public Function Encode_UTF8(astr)
' Auteur : Cyberpat92 02/11/2005
' https://forum.hardware.fr/hfr/Programmation/VB-VBA-VBS/code-conversion-ansi-sujet_79551_1.htm
    Dim c, n, utftext
    utftext = ""
    n = 1
    Do While n <= Len(astr)
        c = AscW(Mid(astr, n, 1))
        If c < 128 Then
            utftext = utftext + Chr(c)
        ElseIf ((c >= 128) And (c < 2048)) Then
            utftext = utftext + Chr(((c \ 64) Or 192))
            utftext = utftext + Chr(((c And 63) Or 128))
        ElseIf ((c >= 2048) And (c < 65536)) Then
            utftext = utftext + Chr(((c \ 4096) Or 224))
            utftext = utftext + Chr((((c \ 64) And 63) Or 128))
            utftext = utftext + Chr(((c And 63) Or 128))
        Else ' c >= 65536
            utftext = utftext + Chr(((c \ 262144) Or 240))
            utftext = utftext + Chr(((((c \ 4096) And 63)) Or 128))
            utftext = utftext + Chr((((c \ 64) And 63) Or 128))
            utftext = utftext + Chr(((c And 63) Or 128))
        End If
        n = n + 1
    Loop
    Encode_UTF8 = utftext
End Function

on pourrait faire un test avec cet autre programme (qui lui n'est pas limpide pour moi)

edit : aucun intérêt pour un autre code après vérification ci-dessous

Bref, je ne sais pas par quel bout prendre ce point remis en cause par PostFinance ! As-tu des contacts auprès de SIX ? Qui est le gardien du temple ? Cela n'empêchera pas certains organismes bancaires de faire ce qu'ils veulent. As-tu la possibilité de t'affranchir des caractères latins diacritiques et tout écrire sans accents ? Peut-être aussi comparer avec ceci https://www.codecrete.net/qrbill/bill ou ceci https://github.com/manuelbl/SwissQRBill (mais c'est du java). Je vais juste regarder de mon côté si un QRCode peut être lu en hexa.

Pour le codage, je viens de vérifier avec un petit fichier texte en utf-8 où j'ai écrit Hélène, et c'est ok, c'est bien le même que dans le fichier py

1. je vais voir si je peux lire un QRCode en hexadécimal genre https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-194/Decoder-un-code-QR
2. après, je ne sais pas si tu avais quelques minutes pour vérifier ...
   1. est-ce que le QRCode refusé passait quand même dans la plateforme de test de Postfinance ?
   2. vérifier leurs dires, à savoir qu'un QRCode sans utf-8 "passe" sur la plateforme de SIX !

@Yvouille

j'ai créé un QRCode avec python et un avec un autre logiciel, je suis en train de comparer le codage en hexa entre les 2

les 2 sont lus avec les mêmes infos, mais le codage hexa est différent

j'essaierai aussi d'en générer un via python sans codifier a priori en utf-8 pour voir si python lui-même transforme en utf-8

edit : impossible de générer le QRCode avec des caractères accentués via python s'il n'y a pas au préalable transformation en utf-8