Bonjour,
Il me semble que si les solutions des diverses plateformes (qui se multiplient incroyablement…) consistaient à proposer une solution complète de gestion clients, on comprendrait mieux les tarifs demandés (les personnes du forum qui s’y sont attelées ont pu mesurer l’ampleur de la tâche).
Par contre, s’il ne s’agit que de programmer de la facturation au coup par coup (mise en forme, transmission, sans oublier un petit stockage pour restituer les flux plus tard), ça paraît tout de suite un peu surévalué (du coup, la multiplication des plateformes est nettement plus compréhensible, ça commence ressembler à des requins qui flairent la bonne occasion…).
C’est également le cas de la transmission de données. Je reste sur mon idée initiale de produire moi-même, à partir de ma solution FM de gestion clients existante, un fichier au format demandé, à déposer sur une plateforme raisonnable qui demanderait un coût minimal pour le service (qui consiste juste à transmettre le fichier à l’administration adéquate, si on ne peut pas le faire directement nous-même).
J’ai donc réussi, comme expliqué précédemment, à mettre en place une exportation des flux au format JSON, et tant qu"à faire, ce n’était pas beaucoup plus compliqué de le faire aussi au format XML. Si ça intéresse quelqu’un, voici les éléments de base que j’ai appliqués…
Au préalable, on a besoin de 3 fonctions personnalisées pour simplifier la mise en forme des lignes XML ( pour JSON, c’est inutile puisqu’il y a la fonction JSONFormatElements qui fait ça très bien):
- ind ( N ) = Si ( N = 0 ; "" ; Substituer ( 10 ^ ( 4 * N ) - 1 ; 9 ; " " ) ) qui rend un texte de N x 4 espaces pour l’indentation
- xml ( K ; T ) = "<" & K & ">" & T & "</" & K & ">¶" qui renvoie une ligne avec une valeur T encadrée par les balises K
- bal ( K ; B ) = "<" & Si ( B ; "/" ) & K & ">¶" qui renvoie une ligne avec la balise K seule de début ou de fin selon que B vaut 0 ou 1
Ensuite l’astuce consiste à définir des variables (toutes celles exigées selon flux de transactions ou de paiements) qui serviront ensuite aux deux formats:
Définir variable ( $var1 ; valeur1 )
Définir variable ( $var2 ; valeur2 )
Définir variable ( $var3 ; valeur3 )
avec valeur pouvant être un nombre ou un texte
Puis on remplit progressivement deux rubriques globales Rjson et Rxml qui contiendront le texte au format souhaité:
Définir rubrique ( Rjson ;
JSONSetElement ( "{}" ;
[ "groupe.var1" ; $var1 ; JSONString ou JSONNumber ] ;
[ "groupe.var2" ; $var2 ; JSONString ou JSONNumber ] ;
[ "groupe.var3" ; $var3 ; JSONString ou JSONNumber ]
)
Définir Rubrique ( Rjson ; JSONFormatElements ( Rjson ) )
Définir rubrique ( Rxml ;
"<?xml version=\"1.0\" encoding=\"UTF-8\"?>¶" &
ind ( 0 ) & bal ( "root" ; 0 ) &
ind ( 1 ) & bal ( "groupe" ; 0 ) &
ind ( 2 ) & xml ( "var1" ; $var1 ) &
ind ( 2 ) & xml ( "var2" ; $var2 ) &
ind ( 2 ) & xml ( "var3" ; $var3 ) &
ind ( 1 ) & bal ( "groupe" ; 1 ) & "¶" &
ind ( 0 ) & bal ( "root" ; 1 )
)
Il n’y a enfin plus qu’à exporter les fichiers
Exporter rubrique ( Rjson ; "Nomdefichier" & ".json" )
Exporter rubrique ( Rxml ; "Nomdefichier" & ".xml" )
L’avantage de faire dans les deux formats, c’est d’abord que c’est amusant de comparer les fichiers obtenus, mais aussi bluffant de rapidité d’un point de vue programmation, une fois qu’on a déterminé les variables et les regroupements nécessaires. Il est notablement plus sûr de n’avoir qu’un seul endroit pour déclarer les variables.
Moralité : jusqu’en septembre 2027, je continue d’utiliser ma solution perso avec les factures PDF remises directement aux clients particuliers, ensuite, je croise les doigts pour que d’ici là les exigences de structure des fichiers de flux soient assez raisonnables pour adapter sans douleur les scripts déjà prêts. Et je choisirai la plateforme qui demandera un prix le plus réduit possible pour la petite opération de transfert.
Cordialement