feat(erp): facturation KissMetrics en dollars, part différée M3 retrouvée, et le format de lettre commerciale #97
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
6abc437c81 |
feat(correspondance): le format de lettre commerciale devient un gabarit réutilisable
Fixé avec le dossier KissMetrics du 24/08 et validé par l'opérateur : « on peut se souvenir de ce format pour les communications avec KM et futurs prospects/clients ». Il ne servira à rien s'il faut le reconstituer à chaque fois — d'où un gabarit, un script, et les raisons écrites. LE TEST DU GABARIT : la lettre du 24/08 s'en régénère à l'identique, au mot près, vérifié par diff du texte extrait. Un gabarit qui ne reproduit pas son propre exemple n'est pas un gabarit. LES CHOIX, ET POURQUOI. Charter pour le texte — dessinée par Matthew Carter pour tenir le petit corps là où d'autres se délitent — et Optima pour les titres. Les deux incorporées au PDF : le rendu est le même chez le destinataire. Chiffres elzéviriens, pour que les montants s'alignent au lieu de faire des bâtons. Deux encadrés, deux usages : le gris porte une question, le rouge sourd ce qui doit être lu en diagonale — UN SEUL par lettre, deux et plus rien ne ressort. Les tableaux portent un <thead>, sans quoi ils perdent leur en-tête en se coupant entre deux pages. LE PIÈGE, consigné parce qu'il coûte une heure à qui le redécouvre : weasyprint NE SAIT PAS rendre Apple Color Emoji. C'est un format bitmap sbix qu'il ignore, et les trois emblèmes 🏹💻🪽 sortent en carrés vides — sans erreur, sans avertissement. D'où correspondance/emblemes/*.png, rendus une fois pour toutes par test/emoji2png.ts, qui passe par Chromium : lui lit la police système. Les PNG sont incorporés en base64 À LA GÉNÉRATION, pas dans le gabarit : un gabarit de 400 Ko dont 97 % de charabia ne se relit pas. Le PDF produit reste autonome. Les trois emblèmes viennent du site — « Gabriel 🪽 Radureau, pour 🏹 réussir vos projets 💻 ». L'arc et l'ange sont dans le nom lui-même. lettre.py proteste au-delà de deux pages : une lettre d'affaires qui déborde ne se lit pas, et la tentation est alors de rétrécir la typographie plutôt que le propos. C'est le propos qu'il faut resserrer. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
|
1cab6f85f7 |
docs(adc-006): l'ancienne méthode n'était pas un défaut — elle représentait l'encaissement
Correction de cadrage demandée par l'opérateur : « pas de "flaw", simplement qu'on a matché les factures. KM a payé en $ et on a reçu en €. On essaie de représenter le plus fidèlement la réalité. » La rédaction précédente présentait la facturation en euros comme un défaut de conception. C'est faux, et c'est injuste envers une méthode qui avait sa cohérence : faire coïncider la facture avec l'encaissement fait dire à la facture ce qui est RÉELLEMENT entré en banque, au centime près. Les quatre factures réglées en portent la preuve. Sa limite ne concerne que les factures NON encore réglées, où il n'y a rien à représenter : le montant affiché n'y est qu'une contre-valeur provisoire, et la note devait l'avouer. C'est là, et là seulement, que le dollar fait mieux — il affiche le montant contractuel, qui lui ne dépend d'aucun taux. D'où le partage retenu, qui n'est pas un compromis mais deux fidélités : euros pour ce qui a été encaissé, dollars pour ce qui reste dû. Chaque facture porte le chiffre qui est vrai d'elle. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
|
01441df5ea |
feat(erp): le retainer KissMetrics se facture en dollars — adc-006 tranchée
L'opérateur a demandé « on ne peut pas emettre de facture en dollars ? ». Si, et
c'est même la bonne réponse ici — au point que la question avait déjà son créneau
au registre : adc-006 était Proposed depuis juillet, sa première question ouverte
étant mot pour mot « USD multicurrency invoices vs EUR-at-settlement ? ».
LE DÉFAUT. Le contrat fixe un prix EN DOLLARS — 2 500 USD en part fixe, 3 000 en
part différée — mais les factures étaient libellées en euros, contre-valeur figée
au taux du jour d'émission. Leur propre note l'avouait : « le montant
effectivement dû en euros sera arrêté au taux du jour du règlement ». Une facture
dont le montant affiché n'est pas le montant dû.
Le coût était réel et mesuré : FAC004, FAC006 et FAC009 ont dû être reprises le
même jour parce que leur contre-valeur ne correspondait pas aux virements reçus.
51,13 EUR d'encaissement manquaient aux livres.
Le client paie d'ailleurs en dollars : les euros reçus varient de 2 147,00 à
2 195,97 pour une prestation à prix fixe, signature d'un virement en devise
converti à l'arrivée par Wise, qui ne détient qu'un solde en euros.
LE DROIT. Une facture peut être libellée dans toute monnaie (CGI art. 289, II,
transposant la directive 2006/112 art. 230) ; seule la TVA à payer doit être
déterminée en euros, et il n'y en a pas — autoliquidation par un preneur hors UE.
Les LIVRES, eux, restent tenus en euros (C. com. art. L.123-22) : la
contre-valeur inscrite n'a pas bougé d'un centime.
PÉRIMÈTRE. Les quatre factures NON RÉGLÉES, aucune n'ayant été transmise :
FAC005, FAC007, FAC010, FAC011, toutes portées à 3 000,00 USD. Les quatre réglées
restent en euros — leur montant est exactement ce qui a été encaissé et rapproché
avec la banque. Chaque facture dit ainsi sa propre vérité.
CE QUE adc-006 DOIT CONSIGNER, ET CONSIGNE. adc-002 pose qu'« une facture validée
n'est jamais ajustée pour raison de change ». Trois l'ont pourtant été le 24/08.
L'opérateur l'a arbitré au motif qu'aucune n'avait été transmise au client, et
adc-006 supprime la situation qui rendait l'arbitrage nécessaire : une facture en
dollars n'a aucune raison d'être ajustée, son montant ne dépendant d'aucun taux.
adc-002 s'en trouve restreinte, pas abrogée — les écarts de change continuent
d'aller en 766 et 666, et deviennent le cas normal au lieu de l'exception.
test/setInvoiceCurrency.ts. Deux pièges consignés. `PUT /invoices/{id}` ACCEPTE
`multicurrency_code`, répond 200, et n'applique rien : seule l'interface change
la devise. Et ce changement ABÎME la ligne — Dolibarr recalcule le montant en
devise depuis les euros et le taux du dictionnaire, puis le changement de taux
fige la devise et recalcule les euros, si bien que la contre-valeur dérive. Le
script réunit donc les deux opérations, réécrit la ligne ENTIÈRE (le PUT n'est
pas un PATCH) et refuse si la contre-valeur euro a bougé d'un centime.
Le juge a relevé, à raison, que le titre du change-set débordait de son contenu :
le passage en devise est fait par le script, en amont. Accepté et consigné au
gate ; le manifeste n'a pas été retouché pour ne pas rompre l'empreinte sur
laquelle le gate est scellé. Son residual risk — vérifier la multidevise en
production — est honoré. Juge post-gate PASS sans dérive.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
||
|
|
3b6c93404e |
feat(erp): FAC011 — la part différée du cycle M3 n'avait jamais été facturée
3 000 USD manquants, découverts en assemblant le dossier client complet. La cartographie des cycles ne laisse pas de doute : M1, M2 et M4 ont chacun leur part fixe ET leur part différée ; M3 n'avait que sa part fixe (FAC008, réglée le 20/07). La facture pro forma PR2607-0001, remise au client en juillet, annonçait pourtant l'émission de cette part différée pour le 24/08/2026 — soit le jour même. C'est la date retenue : la numérotation reste chronologique au sens de l'article 289 du CGI, et l'échéance reste au 23/10/2026, trois mois après la fin du cycle M3. Le retard est écrit dans la note de la facture plutôt que masqué par une date d'émission rétroactive, qui elle romprait la chronologie. LE JUGE A POSÉ LA BONNE QUESTION. Il demandait si le différé de trois mois court depuis l'émission ou depuis la fin du cycle — les deux lectures ne divergent que pour M3, dont la facture est tardive : 23/10 contre 24/11. La pro forma tranche en toutes lettres et dans ses deux versions : « émise le 24/08/2026, à échéance du 23/10/2026 », et « paiement différé à 3 mois DE LA PRESTATION ». Retenir une autre date reviendrait à s'écarter d'une annonce déjà faite au client. Preuve en 02b-preuve-echeance.txt. CE QUI A ÉTÉ RETIRÉ DU CHANGE-SET EN COURS DE ROUTE. Une première version ajoutait la clause de pénalités L.441-10 à FAC001, FAC002 et FAC003, qui en sont dépourvues. L'opérateur a précisé le circuit réel : pendant la phase d'audit (janvier-février 2026), c'est WISE qui a émis les factures, en reprenant les identifiants internes de Dolibarr. Ces trois-là ONT donc été transmises au client. Modifier leur note aujourd'hui ferait diverger le registre interne du document que le client détient — l'inverse du but recherché. Le défaut de mention est réel mais historique, sur des factures réglées : consigné, pas réécrit. Depuis avril 2026 en revanche, KissMetrics vire le montant sur le compte Wise sans recevoir aucune facture. C'est ce qui a permis de reprendre FAC004, FAC006 et FAC009 plus tôt dans la journée, et c'est le dossier du 24/08 qui porte ces factures au client pour la première fois. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |