Adresses

Les adresses servent à identifier les lieux utiles aux parcours: siège, facturation, retrait, livraison, visite, rendez-vous ou informations contractuelles.

Types d'adresses

Techniquement, une adresse ne porte que quatre types possibles (champ indexedMeta.type):

Le « siège social », l'« adresse de contact » et l'« adresse de visite » ne sont donc pas des types techniques distincts:

• Siège social: un indicateur porté par l'organisation (organisation.meta.headquartersAddressShortId), positionnable uniquement sur une adresse de type BILLING.
• Adresse principale de facturation: un indicateur similaire (organisation.meta.billingInformation.addressShortId), lui aussi réservé aux adresses BILLING.
• Contact: n'importe quelle adresse peut porter une liste de contacts (utilisateurs, champ meta.contactShortIds), quel que soit son type.
• Visite: un rendez-vous de type visite (appointmentType: VISIT) utilise, comme un retrait (PICKUP), une adresse de type REMOVAL; c'est le rendez-vous qui porte la distinction visite/retrait, pas l'adresse.

Workflow adresse

flowchart TD
  besoin["Besoin d'adresse"] --> proprietaire["Toujours rattachée à une organisation"]
  proprietaire --> saisie["Sélection via autocomplétion ou saisie manuelle"]
  saisie --> controle["Contrôle du type et de la complétude"]
  controle --> valide{"Adresse utilisable ?"}
  valide -->|Non| correction["Demander correction"]
  valide -->|Oui| usage{"Usage"}
  usage --> facturation["Adresse principale de facturation (type Facturation uniquement)"]
  usage --> siege["Siège social (type Facturation uniquement)"]
  usage --> selection["Sélection pour un lot, une vente ou un rendez-vous"]
  selection --> groupe["Adresses de l'organisation active + adresses des organisations liées du groupe"]
  usage --> visibilite["Visibilité marketplace (rendez-vous, option 'Adresse visible')"]

Règles de gestion

• Toute adresse est rattachée à une organisation (organisationShortId obligatoire, pas de rattachement direct à une personne). Un lot, une vente ou un rendez-vous référence une adresse existante de l'organisation; il ne la crée pas et n'en devient pas propriétaire.
• La création ou la modification exige un type et un pays; l'intitulé est pré-rempli à partir du type si l'utilisateur ne le renseigne pas. Le numéro, la rue, le code postal et la ville sont soit renseignés automatiquement par la sélection d'une suggestion (autocomplétion Google Places), soit obligatoires en saisie manuelle.
• Seule une adresse de type BILLING peut être définie comme adresse principale de facturation ou comme siège social de l'organisation.
• À l'inscription de l'organisation et lors de la vérification KYB, une adresse « principale » doit être configurée: elle sert à la fois de siège social et d'adresse principale de facturation. Tant qu'elle n'est pas définie, l'étape ne peut pas être validée (message affiché: « Avant de poursuivre la vérification de votre organisation, sélectionnez l'adresse de son siège social. Elle sera également utilisée comme adresse principale de facturation. »). La première adresse créée lors de l'onboarding se voit automatiquement attribuer ces deux rôles.
• Lors du choix d'une adresse pour un lot, une vente ou un rendez-vous, les adresses proposées sont regroupées par organisation: celles de l'organisation active sont filtrées sur le type requis (ex. REMOVAL pour un rendez-vous), tandis que celles des organisations liées du groupe (parentes et filiales) sont toutes proposées, sans filtre de type.
• Un rendez-vous de retrait ou de visite utilise une adresse de type REMOVAL. Sa visibilité sur la marketplace est décidée au cas par cas via l'option « Adresse visible » (désactivée par défaut à la création); même visible, seuls le code postal, la ville et le pays sont affichés publiquement — jamais le numéro ni la rue.
• Une adresse peut être associée à des contacts (utilisateurs) choisis parmi les organisations du groupe de l'organisation propriétaire.
• La création, la modification, la définition en adresse principale ou en siège, et la suppression sont réservées aux utilisateurs disposant du droit ORGANISATION.ADDRESS.MANAGE.

Ce qui est implémenté

• Une adresse peut être créée, lue, mise à jour ou supprimée via l'API dédiée (POST/GET/PUT/DELETE /addresses).
• La liste des adresses d'une organisation exige toujours un filtre par organisation (organisationShortId); la lecture d'une adresse unique se fait par son identifiant (addressShortId).
• Un endpoint dédié (/addresses/grouped) retourne les adresses de l'organisation et de son groupe (parentes et filiales), utilisé par les parcours de sélection d'adresse (lot, vente, rendez-vous).
• Le filtrage par type fonctionnel (facturation, retrait, livraison, autre) est appliqué côté front sur la liste retournée par l'API, pas par un paramètre serveur dédié.
• La définition de l'adresse principale de facturation et celle du siège social sont deux actions distinctes, chacune mettant à jour les métadonnées de l'organisation, toutes deux limitées aux adresses de type BILLING.
• La couche commune front (shared-business) contient les composants, formulaires et actions d'adresse partagés entre les frontaux (création, édition, suppression, sélection groupée).
• Les parcours d'inscription et de vérification KYB de l'organisation imposent la configuration d'une adresse principale (siège + facturation) avant de continuer.
• Les rendez-vous (retrait, visite) référencent une adresse existante de l'organisation et portent leur propre indicateur de visibilité publique (addressVisible).

Résolu: la « suppression » d'une adresse (vérifiée dans le service backend auctelia/addresses) n'efface jamais la ligne en base. L'appel DELETE détache simplement l'adresse de son organisation (organisationShortId mis à null); la ligne elle-même subsiste. C'est pour cela qu'aucun contrôle « adresse encore utilisée par un lot ou un rendez-vous actif » n'est nécessaire ni observé: un lot ou un rendez-vous qui référence déjà l'adresse continue de fonctionner, seule sa réapparition dans les listes de l'organisation disparaît.

Impact frontaux