ProcedaProceda Essai 14 jours

Bloquer une commande sans dépôt attestation : workflow Achats

Bloquer une commande sans dépôt attestation : workflow Achats

Pourquoi bloquer à la commande et pas seulement au paiement

Le blocage paiement ERP est le dernier rempart, mais trop tard si les équipes ont déjà reçu la prestation sur site. Bloquer à la création du bon de commande (BC) ou de la demande d'achat :

  • empêche l'engagement de nouvelle dépense ;
  • signale immédiatement au terrain que le prestataire est rouge ;
  • complète la chronologie de vigilance avant intervention.

Les relances J-45, J-30 et J-7 ont été envoyées. L'attestation est expirée. Le registre affiche rouge. Pourtant le conducteur de travaux crée un bon de commande « exceptionnel » dans l'ERP et le prestataire intervient le lundi. Sans verrou système, toute la séquence de relance ne sert qu'à décorer un dossier Excel. Le blocage de commande sans dépôt d'attestation transforme la conformité L.8222-1 en règle opérationnelle, pas en souhait du DAF.

Ce guide décrit le workflow Achats, le lien avec l'ERP, les seuils, les exceptions tracées et les moyens d'éviter le contournement terrain.

Ordre logique : relance tracée → statut rouge → blocage BC → si BC passé par exception, blocage paiement en secours.

Architecture du workflow en cinq étapes

Étape 1 : Source de vérité

Le registre prestataires (portail ou outil dédié) expose pour chaque SIREN :

  • date fin validité attestation ;
  • statut vert / orange / rouge ;
  • date dernière relance ;
  • indicateur « blocage actif » oui/non.

L'ERP ne recalcule pas la validité seul : il interroge le registre ou reçoit une synchro quotidienne (API, fichier, saisie contrôlée sur fiche tiers).

Étape 2 : Règle de déclenchement

Blocage si :

  • statut = rouge, OU
  • date du jour > date fin validité ET montant cumulé 12 mois glissants ≥ 5 000 € HT (seuil L.8222-1).

En orange J-7, alerte sans blocage selon votre charte. En rouge, blocage systématique des nouveaux BC.

Étape 3 : Point de contrôle ERP

À la validation du BC (ou à la création selon maturité IT) :

  • lecture SIREN fournisseur ;
  • si blocage actif → statut BC « rejeté conformité » + message explicite ;
  • notification au créateur du BC et au référent Achats.

Étape 4 : Parcours de dérogation

Workflow exception avec motif, durée max quinze jours, validateur DAF ou directeur site + copie conformité. Pas de dérogation permanente.

Étape 5 : Levée du blocage

Dépôt attestation sur portail, vérification code sécurité, passage au vert → synchro ERP sous 24 h → BC débloqué.

Paramétrage ERP : champs et messages

Sur Sage, EBP, Cegid ou ERP cloud, créez ou mappez :

Champ fiche tiersContenu
attestation_valide_jusquauDate fin validité
statut_conformite_socialeV / O / R
blocage_bc_actifOui / Non
date_derniere_synchro_registreHorodatage

Message utilisateur au rejet : « Fournisseur {nom} : attestation URSSAF non valide. Contactez conformite@. Réf. registre {id}. »

Évitez les messages techniques « erreur SQL » : le conducteur de travaux doit comprendre l'action attendue.

Seuils et périmètre

Seuil 5 000 € HT : aligné sur L.8222-1. En dessous, votre politique peut autoriser le BC avec alerte, mais documentez le choix en comité. En audit, un blocage systématique au-dessus du seuil est plus simple à défendre.

Montant cumulé : douze mois glissants, toutes entités du groupe si ERP consolidé.

Types de documents bloqués : BC, demandes d'achat, avenants augmentant le montant, renouvellements contrat-cadre. Les factures seules restent couvertes par le blocage paiement.

Exceptions documentées sans créer de faille

Cas légitimes :

  • Création entreprise < 3 mois : justificatif immatriculation D.8222-5, dérogation quinze jours renouvelable une fois.
  • Retard URSSAF documenté : attestation de dépôt de demande, pas une promesse orale.
  • Urgence sécurité / continuité : panne critique, validateur DG + DAF, durée 72 h max, revue post-incident.

Chaque exception génère une fiche : SIREN, motif, validateurs, date fin, BC concerné, plan de régularisation.

Interdit : exception « le commercial connaît bien le gars » sans trace.

Éviter le contournement terrain

Les contournements classiques :

  • BC au nom d'une autre entité du même groupe prestataire (mauvais SIREN) ;
  • achat via carte affaires ou frais hors ERP ;
  • sous-traitance non déclarée ;
  • « on commande sur l'autre site du groupe ».

Contre-mesures :

  • contrôle SIREN facture vs BC ;
  • campagne de sensibilisation CODIR : solidarité URSSAF sur la personne morale donneur d'ordre ;
  • échantillonnage mensuel des BC créés pendant dérogation ;
  • alerte si même prestataire rouge sur un site et vert sur un autre (registre groupe).

Le référent site n'a pas le droit de lever un blocage ERP. Il contacte conformité.

Coordination avec la séquence de relance

Le blocage ne doit pas surprendre. La charte annonce : « À défaut de dépôt avant expiration, blocage des commandes dès le lendemain. » Les mails J-30 et J-7 rappellent cette règle.

Chronologie idéale exportable en audit :

  1. J-45, J-30, J-7 tracés ;
  2. Expiration → rouge ;
  3. Tentative BC → rejet ERP horodaté ;
  4. Éventuelle escalade N+1 ;
  1. Dépôt → vert → BC autorisé.

Reporting et comité Achats

Tableau mensuel :

  • nombre de BC bloqués ;
  • délai moyen entre blocage et régularisation ;
  • nombre de dérogations accordées / refusées ;
  • top 5 SIREN récurrents en blocage.

Un prestataire bloqué trois fois en douze mois déclenche revue stratégique (panel, co-traitance, sortie).

Différence avec le blocage paiement

MomentBlocage commandeBlocage paiement
ObjectifPas d'engagement nouveauPas de sortie de trésorerie
TimingAvant interventionAprès facture
Efficacité terrainÉlevéeMoyenne si prestation faite

Les deux se complètent. Ne vous contentez pas du paiement si les équipes peuvent encore commander.

Communication fournisseur

Email type à J-0 ou à premier BC bloqué :

« Votre statut conformité est rouge depuis le {date}. Nos systèmes bloquent toute nouvelle commande jusqu'au dépôt de l'attestation sur {lien}. Contact : {email}. »

Ton factuel, pas punitif. Le fournisseur doit savoir comment se débloquer.

Livrable à emporter

Workflow blocage commande

``` [DÉBUT] │ ├─ Registre : statut prestataire ? │ ├─ VERT → BC autorisé (fin) │ ├─ ORANGE → BC autorisé + alerte créateur (fin) │ └─ ROUGE → suite │ ├─ Montant cumulé 12 mois ≥ 5 000 € HT ? │ ├─ NON → BC autorisé avec alerte DAF (si politique < seuil) (fin) │ └─ OUI → suite │ ├─ Dérogation active et non expirée ? │ ├─ OUI → BC autorisé, tag DÉROGATION (fin) │ └─ NON → BC REJETÉ ERP │ ├─ Notification : créateur BC + conformite@ + référent site │ ├─ Mail auto prestataire : lien portail + date blocage │ └─ Si rouge > 7 j → déclencher escalade N+1 (parallèle) [DÉPÔT ATTESTATION] │ ├─ Vérification code sécurité URSSAF ├─ Passage VERT registre ├─ Synchro ERP < 24 h └─ BC débloqué [FIN] ```

RACI synthétique

ActionAchatsConformitéDAFSiteERP admin
Définir règle seuilRCAII
Paramétrer blocage ERPCCAIR
Valider dérogationCRACI
Créer BC terrainRIIRI
Lever blocage (technique)IRIIR

Légende : R = Responsible, A = Accountable, C = Consulted, I = Informed

Checklist déploiement (30 jours)

  • [ ] Semaine 1 : valider seuil et exceptions en comité
  • [ ] Semaine 2 : paramétrer champs ERP + message rejet
  • [ ] Semaine 3 : synchro registre test sur 10 SIREN
  • [ ] Semaine 4 : rodage alertes sans blocage effectif
  • [ ] J+30 : activation blocage + mail fournisseurs actifs

Indicateurs de succès à 90 jours

  • 100 % des BC rouges ≥ seuil bloqués sans contournement détecté
  • Délai médian blocage → vert < 14 jours
  • Zéro dérogation > 15 jours sans clôture

Sur le même sujet


Proceda centralise le registre de vigilance prestataires : attestations URSSAF, relances tracées, feux tricolores. Essai 14 jours, sans carte bancaire. Démarrer

Tenez votre registre prestataires à jour. Relances URSSAF tracées, veille RNE quotidienne, portail de dépôt sans compte, export audit.

Essai 14 jours · sans CB