AkiraAkira.dev
2 min de lecture

Laravel SISP 2.1 sépare l'acheteur du client

Sur une facture, le bloc acheteur désigne une entité fiscale. La version 2.1 arrête de le confondre avec le contact qui a payé.

aussi en EN PT

Trois lignes de Laravel SISP 2.1 résument la release entière.

src/Actions/GenerateInvoicePdfAction.php

$buyer = EntityBuilder::make()
    ->name($taxName ?? $invoice->customer_name ?? $transaction->customer_name ?? '')
    ->address($taxAddress ?? $invoice->customer_address ?? $transaction->customer_address ?? '')
    ->vat($invoice->customer_vat ?? $transaction->customer_vat ?? '')

Le bloc acheteur du PDF privilégie désormais l’identité fiscale, et revient au contact quand elle est absente. Avant 2.1, la deuxième moitié de chaque chaîne était la seule qui existait.

Un paiement porte deux identités

Un responsable règle l’abonnement de sa société avec sa carte personnelle. Le contact, c’est lui. La facture, elle, appartient à la société: raison sociale, numéro fiscal, adresse fiscale. Ce document est écrit pour l’administration, pas pour une boîte mail.

Le package ne savait stocker que le contact. La version 2.1 ajoute quatre champs à côté, sans en remplacer aucun.

src/ValueObjects/CustomerData.php

public ?string $vat = null,
public ?string $taxName = null,
public ?string $taxEntityType = null,
public ?string $taxAddress = null,

La requête de paiement les valide en sometimes|nullable. La transaction les stocke, la facture les recopie au moment de sa génération. Cette duplication est voulue: une facture est un document, et un document doit rester exact même après la mise à jour de la transaction dont il provient.

Renommer une colonne coûte plus cher

L’objection évidente consiste à réutiliser l’existant. Traiter customer_name comme la raison sociale, demander aux marchands d’envoyer la société, et économiser quatre colonnes.

Le premier ticket de support suffit à casser ce raccourci. Le support cherche la personne qui a payé. La comptabilité cherche l’entité qui doit. Une colonne unique répond à l’une et ment sur l’autre, et le mensonge se révèle au pire moment, celui où quelqu’un tente de rapprocher un paiement introuvable.

La compatibilité vient de la chaîne, pas d’un drapeau

Un marchand qui n’envoie rien de nouveau reçoit le PDF d’avant, à l’identique. Un marchand qui envoie customer_tax_name et customer_vat reçoit un document classable en comptabilité. Aucune option à activer, aucune migration de données à surveiller.

C’est la propriété que je cherche dans une release mineure: le nouveau comportement se déclenche par la présence de la donnée, jamais par une configuration que le marchand doit découvrir.

Une facture n’appartient jamais à celui qui clique. Elle appartient à celui qui répond de l’impôt.

partager