Hello les amis,
ça fait un bail que je tourne autour de la question alors je me lance …
Il y a quelques années nous recevions nos factures par la poste, le traitement était donc j'ouvre l'enveloppe et je pose le papier dans la pile/le classeur/la poubelle.
Ce journal ne s'adresse donc PAS à la catégorie "facture -> poubelle" qui a beaucoup gagné au passage au numérique, il suffit de ne pas lire le mail d'information comme quoi la facture est disponible sur votre compte client.
Par contre pour tous les autres humains qui classaient leurs factures (perso ou pro peu importe) au fil de l'eau et qui aujourd'hui perdent en moyenne 2 à 10 minutes pour chaque facture qu'il faut aller télécharger sur le portail client (différent de chaque fournisseur) j'ai une proposition à vous faire.
Après avoir passé des heures à écrire des web scrappers, à devoir les réécrire chaque fois qu'un fournisseur change de "look" ou ajoute une "nouvelle pub" sur son portail client etc.
Je me dis qu'il est temps de proposer un truc propre en normalisant un chemin d'api qui serait donc systématique et qu'il suffirait ensuite d'implémenter une seule fois dans un logiciel "collecteur de factures" pour que ça tourne tout seul.
J'ai cherché mais je n'ai pas trouvé de RFC ou de norme à ce sujet, si vous avez connaissance d'une telle chose merci de me l'indiquer sans tarder !
Je propose donc de lancer l'idée OpenBusinessAPI résumée en obapi.org (je fais cadeau du moyen mnémo technique pour s'en souvenir "ho bapi ho bapi bapi blue ho bapi blue").
On normerait donc un chemin d'api, et une suite super basique de commandes auth/key/list/get qui permettrait de télécharger les factures.
Votre fournisseur indique qu'il est compatible obapi -> hop en 2 secondes vous entrez votre login/pass d'accès au "portail client" et votre appli obapi client fait le reste.
Oui c'est dingue mais vous n'avez pas envie d'y croire ?
Un lien pour l'instant: https://obapi.org … et un 2° sur le forum dolibarr où j'ai commencé à en parler : https://www.dolibarr.fr/forum/t/lancement-dune-idee-un-peu-folle-obapi/41931
# Force à toi
Posté par azmeuk (site web personnel) . Évalué à 10. Dernière modification le 05 janvier 2023 à 12:40.
Je n'ai aucune énergie à donner dans cet effort, mais je soutiens moralement cette idée. C'est en effet une tâche de gestion absolument rébarbative et j'ai déjà souhaité qu'une telle solution existe.
Il y a un problème similaire que j'aimerais voir traité, mais avec des considérations de sécurités qui le rendent encore plus difficile. Je parle bien entendu d'une API normée pour accéder à des comptes bancaires.
Force à toi
[^] # Re: Force à toi
Posté par windu.2b . Évalué à 5.
Puisqu'on en est à parler du bancaire : à quand la portabilité de l'IBAN ?
On dit souvent que les Français sont attachés à leur banque, mais c'est surtout qu'ils sont démoralisés à l'idée de se farcir les whatmille démarches pour signaler leur changement de compte à tous les organismes concernés.
Même si la situation s'est un peu amélioré ces dernières années (la nouvelle banque se chargeant d'interroger la banque qu'on quitte, pour connaître les destinataires des prélèvements réguliers), ça ne marche jamais à 100% (y en a toujours qui ne prennent pas en compte la demande automatisée), et il faut souvent ensuite confirmer par courrier qu'on autorise le prélèvement.
[^] # Re: Force à toi
Posté par PR . Évalué à 2. Dernière modification le 05 janvier 2023 à 20:05.
L’IBAN n’est pas rattaché à une personne (juridiquement parlant).
Mort aux cons !
[^] # Re: Force à toi
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Les prélèvements c'est pénible, mais l'organisation qui veut prélever a intérêt à prendre en compte rapidement le changement.
Pour les versements par contre, tu peux parfaitement tomber sur un service mollasson qui s'en fiche que tu reçoives ton argent 2 ans plus tard.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Force à toi
Posté par Dring . Évalué à 10.
Mais ça existe ! En Grande-Bretagne, c'est OpenBanking, pour le reste de l'Europe c'est PSD2. En général, les banques proposent au moins 2 APIs :
La réglementation n'est pas venue avec une spécification d'API, mais il y a un standard de fait : STET. Tu peux aller voir là : https://www.stet.eu/en/psd2/.
# Woob
Posté par P@sNox Nox (site web personnel) . Évalué à 7.
C'est pas ce que fait déjà woob? (Web out of browser)
[^] # Re: Woob
Posté par Glandos . Évalué à 6.
C'est aussi le fer de lance de CozyCloud
[^] # Re: Woob
Posté par rycks . Évalué à 5.
C'est justement en pensant à eux que je me dis qu'on pourrait grandement leur simplifier la vie si - par exemple - tous les logiciels libres de facturations respectaient la même norme (pour commencer) …
Je vois bien proposer à cozy d'implémenter le client obapi et "voir" le résultat sur 5 ou 10 entreprises (fournisseurs) qui utilisent dolibarr par exemple :)
eric.linuxfr@sud-ouest.org
[^] # Re: Woob
Posté par Liorel . Évalué à 3.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Woob
Posté par rycks . Évalué à 3.
Liorel, je suis 100% d'accord mais je cherche toujours ne serait-ce que le 1er "compétiteur" sur ce standard auquel j'aimerais me conformer et pour lequel j'aimerais faire la promotion …
eric.linuxfr@sud-ouest.org
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Woob
Posté par arnaudus . Évalué à 4.
Les pannes, c'est la version technique qu'un problème plus profond: l'accès au site via un système comme Woob est interdit par les conditions générales d'utilisation. Quand c'est un truc où tu es le produit, comme Twitter, tu ne risques que l'exclusion, pas de préjudice majeur. Quand c'est ta banque, j'imagine qu'ils peuvent te couper ton accès web (en tout cas, c'est ce que je ferais si j'étais la banque).
Même si les applications et sites bancaires ne sont pas pratiques, ils sont un élément majeur de la sécurité de l'accès aux données et aux autorisations bancaires. Un bug dans Woob, et paf, un virement n'est pas fait, ou est fait 5000 fois, toutes les cartes sont mises en opposition, bref, ça peut rapidement être l'horreur, et je ne vois pas comment on peut rattraper ça, puisque l'utilisation de ces logiciels est interdite.
[^] # Re: Woob
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 7.
Bon, mais la proposition d'API discutée ici est en lecture seule donc il n'y a pas du tout les mêmes problèmes de sécurité. Il s'agit de voir ses factures, pas de les régler.
[^] # Re: Woob
Posté par orfenor . Évalué à 5.
Faut nuancer beaucoup quand même: je tombe régulièrement sur des gros services, dont mes 2 banques, qui utilisent Budget Insight (la version pro de Woob). En lecture, comme ce qui est proposé par obapi.
[^] # Re: Woob
Posté par moules . Évalué à 5.
C'est un sujet d'interprétation, woob peut être perçu comme un navigateur qui effectue automatiquement les opérations que tu aurais faites, mais c'est bien toi qui te connecte, il n'y a pas de violation des CGU.
Par contre je suis d'accord avec toi que réaliser des opérations sensibles comme l'émission d'une transaction bancaire est dangereux (même si il est implémenté dans woob de manière à ce que tu confirmes avec le récapitulatif issu du site).
[^] # Re: Woob
Posté par floriang . Évalué à 3. Dernière modification le 14 janvier 2023 à 14:30.
Pas totalement en réalité, car il y a bien un service que des banques proposent : l'agrégation de comptes (via Budget Insight). Et ça nécessite de leur fournir tes id/mdp des concurrents.
Idem pour Digiposte.
# Et le Mail
Posté par abriotde . Évalué à 4. Dernière modification le 05 janvier 2023 à 14:02.
J'approuve tout a fait dans le sens ou il est scandaleux de devoir se connecter à un serveur pour récupérer sa facture, son bulletin de salaire… C'est une tâche lourde qui n'est, selon moi, pas RGPD dans le sens ou de ce fait mon fournisseur sait si je regarde ma facture, quand et même de quel endroit (avec mon IP), il peut la changer sans me prévenir discrêtement…
Cependant plus qu'une couche supplémentaire, je voudrais militer pour un envoi par mail. C'est un protocole ouvert, standard, qui fonctionne extrêment bien et qui est le pendant numérique naturel du courrier. Alors pour simplifier le traitement on pourrait peut-être imaginer un standard d'envois. On pourrait même imaginer activer l'option pour l'envoyer en crypter si on transmet sa clé publique…
[^] # Re: Et le Mail
Posté par rycks . Évalué à 10.
Depuis peu j'ai intégré un point important par rapport à ce point de vue.
Vous avez entendu parler des arnaques aux faux RIB sur les factures ? voici un truc qui arrive souvent : mr x se fait piquer son login/pass à sa boite mail. Le (méchant pirate) lui détourne les factures, remplace le rib du fournisseur par son rib de pirate et collecte le pognon. L'arnaque n'est découverte souvent que de longues semaines plus tard lorsque l'entreprise fait la relance des impayés.
Ça arrive bien plus souvent que vous ne croyez.
Solution alternative: indiquer au client qu'une facture est disponible sur votre serveur via son portail client … il vient télécharger l'original et vous êtes "sûr" que le document n'a pas été altéré par un tiers.
Il y a d'autres solutions pour éviter ça comme par exemple sceller le document mais ça demande à ce que l'utilisateur final fasse l'usage d'un lecteur de document compatible (au pif en pdf la visionneuse js ne le fait pas) … et sache détecter un document dont le certificat aurait été altéré … sauf que si le pirate est pas con au lieu de "casser" le scellement il va tout simplement livrer un pdf sans certificat et donc le client aura un pdf non scellé sans savoir que l'original l'était !
Une autre serait d'envoyer un deep-link dans le mail, mais là encore ça me dérange car les outlook/gmail et autres pré-téléchargent le document et donc aucune confidentialité dans l'affaire. Et ça rejoint un autre contre-argument pour la réception par mail : à moins d'avoir son serveur mail perso la réception des factures par mail est une catastrophe au niveau confidentialité des données … le facteur peut tout savoir.
Perso je continue d'envoyer mes factures (scellées) par mail à mes clients … mais … j'avoue que j'hésite de plus en plus à conserver cette approche.
eric.linuxfr@sud-ouest.org
[^] # Re: Et le Mail
Posté par abriotde . Évalué à 4.
C'est 2 choses différentes. Les factures, c'est juste pour te demander de payer, pas pour recevoir de l'argent. Pour changer ton RIB en général la démarche est autrement plus complexe. Si tu parles d'un mail qui te demande un prélèvement automatique, c'est totalement autre chose, l'un n'entraine pas l'autre. Ou alors je n'ai pas compris l'explication.
[^] # Re: Et le Mail
Posté par Dring . Évalué à 7.
Le mail est ouvert, oui. Et tellement facile à pirater.
Mes factures ne concernent que moi, j'ai pas envie que n'importe quel hacker bien outillé puisse se les procurer.
D'ailleurs, même les mails qui sont sous la forme "vous avez reçu une facture, cliquez ici pour la récupérer" sont déjà la source de sueurs froides de tous les experts en sécurité. Ca habitue l'utilisateur lambda à cliquer sur des liens dans ses mails. Alors que la bonne pratique, encore plus pénible pour l'utilisateur, c'est "vous avez reçu une facture, allez sur notre site web dont vous avez déjà l'adresse pour la récupérer".
Tant qu'à rêver, moi j'ai un autre rêve. Avoir la possibilité de demander l'envoi des factures (et autres documents) sur un espace de stockage sécurisé. Si je suis motivé, j'auto-herberge ce service. Sinon, je peux faire appel à des prestataires; type "ma banque", ou "mon assurreur", ou "mon fourniseur de cloud"…
Avec une API standard qui permet de gérer liste blanche/liste noire, l'envoi de documents, la consultation des documents, la définition de la durée de rétention, des règles de classement automatique, etc…
Et pour passer du rêve à l'utopie délirante, ce type de service pourrait être fourni par l'état pour les plus démunis qui ne peuvent pas se payer ce type de service (critère du genre "non imposable").
[^] # Re: Et le Mail
Posté par PR . Évalué à 4. Dernière modification le 05 janvier 2023 à 20:18.
Ça s’appelle digiposte. Mais ce sera privé, parce qu’un service aussi indispensable permettra de prendre en otage les utilisateurs pour se faire un max de flouze.
PS : le problème fondamental du mail, c’est qu’il ne garantit pas la réception. En plus faut le sécuriser avec du chiffrement.
Mort aux cons !
[^] # Re: Et le Mail
Posté par abriotde . Évalué à 1.
"Ça s’appelle digiposte. Mais ce sera privé" tu veux dire GMail… C'est la même chose : login/mdp et si c'est piraté… Aujourd'hui les boites mails sont les plus sécurisé (authentification double facteur et plus (lieu, terminal habituel…))
Et alors La Poste ne garanti pas la réception non plus (sauf recommendé pas utilisé pour les factures)… sauf qu'en pratique, si tu n'a pas reçu une facture ce n'est pas trop difficile de se connecter au site pour une réclamation… et cela n'arrive à peu près jamais.
[^] # Re: Et le Mail
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Avec Digiposte celui qui dépose une facture dedans reçoit une confirmation.
Après rien ne dit que le propriétaire va consulter son coffre :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et le Mail
Posté par PR . Évalué à 3. Dernière modification le 06 janvier 2023 à 17:02.
L’authentification double facteur n’est pas une garantie de sécurité.
Les youtubeurs en savent quelque chose. Pourtant c’est aussi du google.
PS : C’est d’ailleurs ma dernière étape de sécurisation de ma machine, trouver un moyen d’isoler correctement une session firefox anonyme, et une autre qui prend le bancaire, papiers importants (avec chiffrement sur disque des données privées).
Mort aux cons !
[^] # Re: Et le Mail
Posté par abriotde . Évalué à 0. Dernière modification le 07 janvier 2023 à 22:31.
Qu'est ce qu'à de plus ton coffre-fort par rapport à ta boite mail? Pour moi c'est une petite entreprise aux compétences douteuses closed-source. C'est aussi une porte ouverte. J'ai plus confiance en GMail ou Protonmail…
[^] # Re: Et le Mail
Posté par Dring . Évalué à 2.
C'est pas du tout mon rêve ! Gâcheur de rêve !
Moi, je vise avant tout une norme, avec plusieurs implémentations possibles.
[^] # Re: Et le Mail
Posté par GG (site web personnel) . Évalué à 5.
Quand le serveur en face répond "250 OK", ça signifie qu'il a accepté l'email.
Le problème, c'est quand Gmail, Outlook, etc… répondent ainsi, mais jettent silencieusement l'email…
C'est la faute et la responsabilité du destinataire d'avoir choisi un prestataire email qui choisi de délivrer certains emails, et même de faire croire que l'email sera distribué.
Bonne journée
G
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# facturation électronique
Posté par Jean-Baptiste Faure . Évalué à 9.
Quel lien avec la dématérialisation des factures à partir du 1er juillet 2024 ?
Quelques liens :
https://entreprendre.service-public.fr/actualites/A16076 (dont la section sur les formats de facture)
https://entreprendre.service-public.fr/actualites/A15683
La FAQ "Facture électronique" (version du 30/12/2021) (PDF) du ministère des finances
[^] # Re: facturation électronique
Posté par Pierre86 . Évalué à 1.
En tout cas cette réforme apportera la solution quant à l'envoi et l'obtention des factures sur une plateforme unique et publique, selon un format normé, disponible via un portail Web, une API ou en EDI.
Après la réforme ne concerne que les relations B2B, dans des relations franco-françaises.
Mais on peut imaginer qu'un fournisseur qui émettra des factures dans le cadre de cette réforme à ses clients professionnels émettra ses factures destinées à ses clients particuliers sous le même format (et peut-être même via la plateforme publique, mais je ne crois pas, en l'état de la réforme, que des particuliers pourront se brancher sur cette plateforme pour récupérer les factures).
[^] # Re: facturation électronique
Posté par moules . Évalué à 10. Dernière modification le 07 janvier 2023 à 19:04.
On peut faire le parallèle avec la PSD2 qui a introduit l'obligation pour les banques de fournir des API modernes pour l'accès en lecture aux comptes de paiement et la réalisation de virements.
Premier problème : ces API ne sont utilisables que par des tiers de confiances (Third Party Providers) qui doivent être agréés par l'autorité de régulation nationale (l'ACPR en France). Powens (ex Budget Insight) en fait parti. Par contre, toi en tant que particulier, tu ne peux pas les utiliser, tu es obligé de passer par un TPP qui lui va (probablement) te facturer l'accès au service. Et pour obtenir l'agrément, il est nécessaire d'être une entreprise avec un minimum de capitaux propres et un département de conformité.
Deuxième problème : les banques n'avaient aucun intérêt à mettre ça en place, et ont traîné des pieds. La réglementation a été adoptée en 2017, la date limite de mise à disposition des API était en 2019, il a fallu trois années supplémentaires de collaboration avec les banques pour les aider à résoudre leurs problèmes. Aujourd'hui c'est bien plus stable, mais il y a toujours des fonctionnalités qui manquent dans les API (typiquement les virements groupés).
Troisième problème : même si on peut se féliciter du fait que spontanément des standards ont émergé (Berlin Group ou STET en France), évidement l'implémentation des banques ne les respecte pas, et il est malgré tout nécessaire d'écrire du code spécifique pour chaque banque.
Quatrième problème : la PSD2 ne concerne que les comptes de paiement, ce qui signifie que l'on a accès qu'aux comptes courants et CB. Par contre tout ce qui est épargne, crédit, comptes titres, etc., ne sont pas exposés. Tu n'as donc accès qu'à des informations partielles de tes données.
Cinquième problème : à ce sujet, les informations obligatoires varient d'un pays à l'autre. En France, Powens et d'autres TPPs ont fait un lobbying très actif pour accéder au maximum de données possibles (coordonnées de l'utilisateur, cartes bancaires, etc.), et j'ai moi-même contribué à l'élaboration du standard STET. Par contre impossible de récupérer les relevés PDF qui sont pourtant dans le scope de la PSD2. En revanche, dans d'autres pays où il n'existe pas ou peu de TPP, et donc où il n'a pas été fait un effort de lobbying, les banques ont réalisé leurs API par dessus la jambe et le régulateur est peu attentif.
Bref, quand je vois comment est foutu la réglementation sur l'émission des factures électroniques, beaucoup plus floue que la PSD2, je suis d'avis que ce sera bien de la merde.
# ticket de caisse électronique
Posté par Marc Quinton . Évalué à 2.
quid d'un standard pour recevoir, sans laisser son adresse mail à un tiers, à tous les tiers marchands, une version électronique d'un ticket de caisse, de préférence au format JSON.
J'ai commencé a faire des specs, moi aussi. Ca doit être sur github.
# Cela existe depuis longtemps ...
Posté par Christophe B. (site web personnel) . Évalué à 10.
Bonjour à tous et bonne année 2023, je vous souhaite santé et bonheur ainsi que plein d'énergie pour vos projets.
Alors il me semble que c'est le but de EDIFACT : https://fr.wikipedia.org/wiki/%C3%89change_de_donn%C3%A9es_informatis%C3%A9es_pour_l%27administration,_le_commerce_et_le_transport
je ne sais pas si cela fonctionne encore mais dans les années 90 il y avait le principe d'une BAL => boite aux lettres dans lequel des messages pouvait être lu et déposé.
Pour la sécurité, une carte gérant le protocole X25 et faisant modem plus une couche de sécurité (certainement un cryptage quelconque) devait être ajouté sur le PC qui lui avait un traducteur EDIFAC ou EDIFACT et au final on se retrouvait avec un fichier ASCII importable facilement.
Alors les communications étaient payantes, les messages aussi mais cela valait le cout pour une entreprise
Par contre si je me souviens bien, il n'était plus possible d'écrire soi même un traducteur et forcement en acheter un ou devenir 'Tiers de confiance' vis a vis de la norme EDIFACT ce qui devait couter des sous
J'ai du le mettre en place au moins 1 fois (peut etre plus) et après cela fonctionnait sans problème, c'est d'ailleurs le genre de truc que l'on oublie tellement il marche bien.
par contre le format interne était du style : (exemple piqué sur wikipedia)
UNA:+.? '
UNB+IATB:1+6XPPC:ZZ+LHPPC:ZZ+940101:0950+1'
UNH+1+PAORES:93:1:IA'
MSG+1:45'
IFT+3+XYZCOMPANY AVAILABILITY'
ERC+A7V:1:AMD'
IFT+3+NO MORE FLIGHTS'
ODI'
TVL+240493:1000::1220+FRA+JFK+DL+400+C'
PDI++C:3+Y::3+F::1'
APD+74C:0:::6++++++6X'
TVL+240493:1740::2030+JFK+MIA+DL+081+C'
PDI++C:4'
APD+EM2:0:1630::6+++++++DA'
UNT+13+1'
UNZ+1+1'
bref du xml avant l'heure avec des + au lieu des '<'
mais comme cela devait gérer différents messages pays devises etc … le format était assez indigeste et surtout sujet a interprétations diverses.
Mais le principe était pas mal, enfin des BAL pas du reste, il suffit peut être de rajouter une couche "signature" avec du PGP par exemple, lié au document.
Ce genre de techno devient vite complexe et cela dérape très vite pour devenir du n'importe quoi surtout si tout le monde y met son grain de sable.
Imaginez le noyau Linux sans Linus Torvalds …
[^] # Re: Cela existe depuis longtemps ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Les normes et standards EDI …que de souvenirs.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Cela existe depuis longtemps ...
Posté par Christophe B. (site web personnel) . Évalué à 4.
Oh que oui
certaines technologies enfouies comme l'EDI ou CFT font certainement tourner une partie de l'économie et cela fonctionne avec des logiciels plus vieux que moi :)
Ce que je retient surtout c'est l'entraide à l'époque
pour EDI c'est le directeur info de FRANS BONHOMME de l'époque, j'espère qu'il profite de sa retraite bien méritée, il dirigeait chaque projet de mise en place. Mais quand je dis diriger, il transmettait son expérience et t'apprenais a utiliser et les bases d'EDI, son but que cela fonctionne. J'ai beaucoup appris sur EDI avec lui.
Pareil pour CFT, quelques personnes m'ont appris les tenants et aboutissants de ce logiciel et je les en remercie.
On est loin, très loin des pseudos informaticiens qui cherchent des coupables sans proposer de solutions.
D'ailleurs cela devient tellement courant que même leur mettre le nez dans leur m….. n'est plus rigolo
Bon j'arrête avant de ficher le bourdon a tout le monde ;)
[^] # Re: Cela existe depuis longtemps ...
Posté par rowin . Évalué à 2.
Je confirme, EDIFACT fait encore fonctionner des infrastructures assez critiques ;-)
Et c'est toujours autant une tannée à lire :D
# En suisse...
Posté par thomas . Évalué à 10. Dernière modification le 06 janvier 2023 à 09:40.
En Suisse, on a le système "e-bill" présent chez (presque) toutes les banques: une fois que tu ajoutes le fournisseur (telecom, énergie, whatever) au système "e-bill" dans ton e-banking, le fournisseur envoi la facture électronique directement dans ton e-banking ! Donc tu ne te connecte qu'à un seul endroit (ta banque) et tu vois/valides toutes tes factures.
https://www.ebill.ch/fr/clients-prives.html
et y'a meme un side de démo : https://ebill.ch/ebill-portal/ui/payments/by-due-date
[^] # Re: En suisse...
Posté par rycks . Évalué à 4.
C'est intéressant comme manière de faire … ainsi le banquier qui savait que j'avais dépensé 19,99€ chez mon opérateur de téléphone "avant" sait maintenant aussi à qui j'ai téléphoné grâce à la partie détaillée de ma facture qu'il absorbe au vol.
Alors non, pour moi ce n'est pas du tout le modèle de société que je souhaite avoir.
Je veux pouvoir avoir mes factures chez moi (et d'une manière générale "mes documents" chez "moi") …
Par contre peut-être que e-bill est lié au fait que tous les fournisseurs respectent une API permettant aux banque de ne pas avoir à développer autant de "connecteurs" que de "fournisseurs" (ce qui semblerait assez évident vu que les banques n'aiment pas perdre du temps et donc de l'argent pour rien).
Je vais aller voir tout ça : Merci pour l'info
eric.linuxfr@sud-ouest.org
[^] # Re: En suisse...
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu flingues une solution sous excuse qu'un de tes fournisseur fait des conneries (une facturer c'est pour facturer, la partie détaillée n'a rien à faire la). Plouf. Même sans ce truc c'est juste pourri de mélanger 2 choses comme ça.
Libre à toi de faire comme avant, c'est n'est (pour le moment du moins) interdit, ça ne change pas le sujet ici qui s’intéresse à d'autres choses (être pratique pour la masse qui n'a pas ces "contraintes").
L'idée est pas mal, mais comme d'hab chaque pays fait dans son coin… un jour on réfléchira à ne pas démultiplier les solutions… Genre un truc européen déjà pour commencer, vu que Suisse ou UE on a la même culture (on a déjà l'IBAN et SEPA ensemble, on sait qu'on peut y arriver :) ) la dessus (les US c'est encore autre chose, mais aussi si on peut…)
[^] # Re: En suisse...
Posté par thomas . Évalué à 1.
D'ailleur, je confirme pour mon cas (mon opérateur télécom / ma banque) : pas de facture détaillée (ni communication, ni data).
Conernant les factures, tu peux les télécharger. J'ai fait ça pendant longtemps. Je ne le fait plus. Si demain je veux changer de banque, je téléchargerai les factures passées, en attendant elles sont là (sans compter que la plupart du temps elles sont bien évidement aussi dispo sur le site du fournisseur de service).
bref, je ne dis pas que c'est parfait. Je dis que c'est super pratique.
[^] # Re: En suisse...
Posté par rycks . Évalué à 9.
Heu Zenitram, tu peux regarder tes factures ?
Parceque-moi toutes les factures fournisseurs que je vois passer listent précisément tous les trucs qui sont achetés … oui j'ai pris une facture de tel comme exemple mais regarde une facture de ton magasin de matériel de bricolage, de fournitures etc.
Moi je veux bien que la banque sache que j'ai dépensé 2000€ chez le roi du merlin mais je n'ai pas forcément envie qu'il sache précisément ce que j'ai acheté, tu vois la fuite de données au passage et les conséquences ?
Allez, une facture d'un hébergeur de serveurs en trois lettres, je n'ai pas forcément envie que mon banquier ait la liste de toutes les IP des serveurs que je loue …
Et je reste super soft, le contenu des factures c'est très très révélateur de beaucoup de choses, que ça soit au niveau pro ou au niveau perso.
(Je ne veux pas détourner le sujet mais j'ai la même réaction par rapport à la fin des tickets papiers et qu'on te propose d'envoyer par mail, allez hop le facteur sait maintenant ce qu'il y a dans ton caddie.)
Donc pardon d'avoir "flingué une solution sous excuse qu'un de tes fournisseur fait des conneries" mais mon exemple était pourris et tu t'es pris dedans :)
eric.linuxfr@sud-ouest.org
[^] # Re: En suisse...
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 06 janvier 2023 à 12:17.
J'ai réagi sur "sait maintenant aussi à qui j'ai téléphoné", certains font ça mais d'autres font surtout "X appels nationaux, Y SMS" car on se fout de à qui pour facturer.
L'argument devient plus valable, et on va vers le RGPD (oui, il faut alors faire "confiance"), là on peut débattre (et la je suis votre conversation passivement, parce que bon, si par mail l'hébergeur mail peut aussi lire, je ne suis pas sûr que ce soit mieux pour la masse qui n'a pas d'auto-hébergement) sur ça (et pas "mais il peut techniquement", plutôt sur le légal SVP…).
Allez, je m'enfonce, par exemple :-p.
[^] # Re: En suisse...
Posté par flagos . Évalué à 4.
Alors en pratique, la banque chez moi affiche seulement un menu avec une liste de factures a approuver ou non. Si je veux en savoir plus, je suis redirige vers une page contenant une iframe qui tape chez ebill.ch.
Donc en pratique le banquier ne sait pas forcement grand chose, par contre l’intermédiaire eBill, s'il s'amuse a faire de l'OCR sur les pdfs, peut effectivement recuperer des informations.
Apres, il faudrait lire le contrat de confidentialité, mais dans la FAQ, on trouve déjà ceci:
[^] # Re: En suisse...
Posté par dj_ (site web personnel) . Évalué à 5.
C'est pareil en Belgique avec Zoomit https://www.zoomit.be/fr/
Je reçoit mes factures d’énergie, télécom, taxe poubelle etc
[^] # Re: En suisse...
Posté par Christophe B. (site web personnel) . Évalué à 5.
Je sais que le coq gaulois est le seul animal à chanter les pieds dans la m…..
et
que l'on a tendance a se prendre pour le centre du monde, mais chaque fois qu'il y a de bonnes idées c'est déjà en place chez nos voisins Suisses et/ou Belges.
C'est Dredi !
[^] # Re: En suisse...
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
En l'occurrence, ce n'est pas du tout une bonne idée (pour les raisons de vie privée déjà exposées) et il est tout à fait justifié de la critiquer.
[^] # Re: En suisse...
Posté par Christophe B. (site web personnel) . Évalué à 3.
Toute bonne idée a son coté sombre …
C'est juste que certains font et réfléchisse après, d'autres réfléchisse et ne font pas
d'où l'intérêt de voir ce que font les copains, de critiquer et éventuellement de faire :)
# Après avoir consulter le site
Posté par Christophe B. (site web personnel) . Évalué à 5.
Bonjour,
j'aime beaucoup ton initiative et après avoir lu le site obapi.org j'aurais quelques suggestions basiques d'ordre général
entête / ligne / total : tout fichier véhiculant des données importantes devrait être munis de ceci, cela a plusieurs avantages
d'abord même si on ne transmets rien, il y a au moins une entête et un total
ainsi même le "rien" existe quand tu fais du transfert de fichier c'est important.
Si je ne dois "rien" recevoir cela doit être formalisé, sinon l'absence de fichier est une erreur.
L’entête rappelle le destinataire et d'autres informations
le total rappelle le nombre de lignes et quelque chose pour valider le contenu
cela permet de rejeter un fichier incorrect ou incomplet, ou de le traiter différemment
Ensuite chaque fichier devrait pouvoir être signé par l'émetteur, comme avec PGP par exemple, les signatures de ce style sont intéressantes car les clés peuvent être de PROD de TEST etc …
Bon courage
[^] # Re: Après avoir consulter le site
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
Exiger une signature cryptographique est bien sûr raisonnable, afin d'éviter les faux mais soyons réalistes : imposer cela dans la norme tuerait complètement le projet. Déjà que les fournisseurs typiques auraient beaucoup de mal à déployer cette API, si en plus il fallait signer, on est parti pour des années de réunions, de délais, d'usines à gaz, etc.
[^] # Re: Après avoir consulter le site
Posté par Christophe B. (site web personnel) . Évalué à 2.
Ah c'est vrai tu as raison, l'option simple et de bon sens n'est plus dispo
PGP c'est bien pourtant …
# contacte Akretion
Posté par orfenor . Évalué à 4.
Il me semble que l'équipe d'Akretion, qui travaille sur Odoo, a commencé un projet similaire (avec Alexis de Lattre) pour récupérer ses factures. Ça pourrait les intéresser.
Très bonne idée en tout cas.
# Un grand oui
Posté par Letho . Évalué à 4. Dernière modification le 06 janvier 2023 à 16:11.
C'est à mon sens une excellente idée, qui me trotte également dans la tête depuis quelques temps. Et en tant que dev, je serai ravi de pouvoir participer.
Simple suggestion : je vois qu'il existe deux ressources distinctes pour les représentations JSON des factures et le téléchargement du PDF. Il s'agit pourtant conceptuellement de la même ressource. Ne serait-il pas plus simple de pouvoir préciser dans le header
acceptle format souhaité ?La norme Obapi pourrait dans ce cas préciser que proposer une représentation PDF de la facture est obligatoire.
# Quelques remarques
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 8.
Excellente idée globalement. Quelques remarques toutefois.
"endpoint /obapi/v1" C'est toujours une mauvaise idée d'avoir un préfixe de chemin en dur dans une norme. Le RFC 9205 explique pourquoi.
"errors attributes" Pourquoi ne pas s'appuyer sur le RFC 7807 plutôt que de re-développer une convention ?
La partie sur l'authentification me parait casse-gueule car elle réinvente un protocole de sécurité, ce qui est toujours dangereux. Je préférerai qu'on dise simplement qu'on mette la clé d'EPI dans l'en-tête. Et que l'obtention de la clé d'API dépend du fournisseur.
# Actualisation du 7 janvier
Posté par rycks . Évalué à 3.
Alors,
suite à vos remarques et mails reçus échangés, j'ai un peu chamboulé le site obapi.org pour rester à l'expression de l'idée et une sorte de "démonstration" pour ne pas m'enliser dans une sorte d'implémentation qui nuirait à l'objectif du projet.
J'ai pris contact avec https://www.openapis.org/ pour voir s'ils ont un groupe de travail sur le sujet en espérant que si oui il soit plus avancé que https://github.com/OAI/sig-finance …
eric.linuxfr@sud-ouest.org
# remarques
Posté par flagos . Évalué à 2.
Au sujet d'un éventuel logiciel collecteur de facture, ce qui serait pas mal serait de pouvoir ajouter les informations de paiement au delà du statut "payé".
Je dirais que c'est l'intérêt que je vois a un logiciel de ce genre la: si je suis relancé a propos d'une facture, je peux de suite sortir un numéro de virement.
Autre petit truc aussi, gérer les relances, notamment celles qui sont avec 10 balles en plus ?
# publique visé?
Posté par Skilgannon . Évalué à 1. Dernière modification le 09 janvier 2023 à 22:44.
Une interrogation qui me vient à l’esprit, le public visé est personel ou professionnel ?
Personnellement, ce que je cherche est effectivement quelque chose comme CozyCloud/Woob mais qui fonctionne en permanence (liste facture seul) ou un Kresus/Woob (liste des opérations sur mon compte en lecture seule) mais qui utiliserait un chiffrement à jours pour se connecter à ma Banque.
Impossible de retrouver rapidement, la modification que j’ai dû faire à mon « YunohostBanque » ( il n’y a qu’une application : Kresus) mais de mémoire j’ai dû accepter de baisser les paramètres SSL pour que ca fonctionne …
Pour les professionnels je dirais que l’on pourrait aussi relancer les impayés, autoriser le paiement ou non etc. Il me semble qu’il existe déjà des outils qui ont ces fonctionnalités, il me semble en avoir vu des publicités, mais je ne sais pas du tout comment ils fonctionnent.
# EDF : un mail, un clic
Posté par Marc Quinton . Évalué à 2.
je viens de recevoir un mail de la part de mon fournisseur d'électricité ; il s'agit d'EDF.
en lisant rapidement le message, je vois que je peux acceder à ma dernière facture avec un lien de la forme :
https://espace-securise.edf.fr/services/rest/tunnel/facture-electronique?token=big-tokenet la formulation :
il y a donc un service REST ; mais j'imagine que l'API n'est pas publique. A surveiller.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.