Tous les lots ont-ils la même date limite ?

Périmètre

Commencez par les objets officiels, pas par le calendrier

Fixez l’identité de la procédure et de l’avis courant. Conservez le numéro de version, la date de publication, le statut et l’étape. Relevez ensuite les identifiants de tous les lots exactement comme ils apparaissent. `LOT-0002` reste `LOT-0002`; son intitulé peut être conservé dans un second champ. Cette clé stable permet de raccorder une rectification, une annexe et une enveloppe de dépôt sans dépendre d’un titre susceptible de changer.

Un groupe de lots peut porter certaines règles communes sans devenir un objet auquel le fournisseur remet une offre. Une partie dans un avis de planification peut précéder la définition finale des lots. À l’inverse, eForms représente techniquement une procédure non divisée avec `LOT-0000`. La matrice décrit alors un lot technique unique et précise qu’aucun choix commercial entre lots n’existe. Elle ne fabrique ni lot zéro à sélectionner, ni ligne de groupe à déposer.

Conservez aussi les lots écartés par l’équipe. Leur absence rendrait impossible le contrôle de complétude et pourrait masquer la première clôture de la procédure. Les champs de base sont `procedure_id`, `notice_id`, `notice_version`, `lot_id`, `lot_label`, `lot_kind`, `group_ids`, `offerable_status`, `source_anchor` et `observed_at`. Si les sources officielles ne permettent pas de réconcilier le nombre ou l’identité des lots, l’affectation des dates attend.

Événement

Deux dates proches peuvent régir deux actes différents

Les procédures ouvertes conduisent directement à la remise d’une offre. Les procédures en plusieurs étapes demandent d’abord une candidature ou une demande de participation. Une invitation ultérieure fixe alors la remise de l’offre aux opérateurs retenus. Une négociation peut encore ajouter une offre initiale, une version révisée et une offre finale. Chaque acte mérite sa propre ligne, même s’il concerne le même lot.

La structure eForms sépare ces événements. `BT-131` correspond au délai de réception des offres dans le contexte du lot. Le délai de réception des demandes de participation utilise un autre composant. Les règles publiées comparent aussi le terme des demandes d’information avec la réception de l’offre. Elles n’autorisent aucune fusion sémantique entre ces valeurs.

Adoptez un vocabulaire fermé: `request_to_participate`, `initial_tender`, `tender`, `revised_tender`, `final_tender`, `enquiry`, `site_visit_booking`, `public_opening` et `validity_end`. Ajoutez le libellé original de l’acheteur. Si la source affiche uniquement « date de réponse », recherchez ce qui doit être remis. Tant que cet acte reste indéterminé, la classe vaut `unknown`.

Preuve d’affectation

Une valeur commune doit encore être rattachée à chaque lot

La documentation TED place la date et l’heure `BT-131` dans le `TenderSubmissionDeadlinePeriod` d’un lot donné. Le profil OCDS pour eForms combine ces deux éléments et écrit l’instant dans `tender.lots[n].tenderPeriod.endDate`. Cette localisation constitue une preuve directe. Elle rappelle aussi qu’un agrégateur qui ne conserve qu’un `tenderPeriod` général peut effacer une différence entre lots.

Un règlement de consultation peut créer une portée partagée. Une phrase visant « les lots 1 et 2 » ou « tous les lots » autorise la répétition de la même valeur dans les lignes couvertes. Chaque ligne garde la même ancre et `assignment_basis: explicit_shared`. Si les champs de chaque lot contiennent séparément la même date, la base reste `direct_lot`. L’égalité du résultat ne justifie pas la perte du chemin de preuve.

Une carte de recherche, un bandeau de portail ou une date placée avant la liste ne suffit pas. Le bandeau peut annoncer la prochaine échéance seulement. Une vue mobile peut masquer les valeurs suivantes. Stockez ces affichages comme observations secondaires. Ils deviennent prescriptifs pour un lot lorsque le texte ou le modèle de données établit la relation.

Les sources remplissent des fonctions différentes. L’avis publie une information officielle, le règlement décrit la remise, le portail matérialise les enveloppes et l’invitation gouverne une étape réservée. Une règle unique de priorité serait fragile. Si deux sources actuelles et correctement délimitées donnent des heures incompatibles au même lot et au même acte, la matrice retient `conflicted` et transmet le dossier à la vérification des conflits de délai.

• Preuve directe: la date, l’événement et l’identifiant du lot partagent le même contexte.
• Preuve partagée: une disposition nomme les lots couverts ou vise explicitement leur totalité.
• Inférence refusée: seule la mise en page relie la date et le lot.
• Conflit: deux instructions actuelles prescrivent des valeurs incompatibles au même périmètre.

Cas fictif

Une consultation peut avoir une date commune et une exception prouvée

Considérons la consultation fictive `FR-MOB-2026-41` portant sur des enquêtes de mobilité. Le règlement en version 03 fixe la réception des offres des lots 1 et 2 au 18 novembre 2026 à 16:00 +01:00. Le champ du lot 3 et son enveloppe dédiée indiquent le 25 novembre à la même heure. La page générale affiche « prochaine date limite: 18 novembre ». Cette mention décrit correctement la première échéance sans dire que le troisième lot ferme ce jour-là.

Les lignes 1 et 2 reçoivent `confirmed_explicit_shared`, avec l’article du règlement comme ancre commune. Le lot 3 reçoit `confirmed_direct`, appuyé par son champ officiel et l’instruction de l’enveloppe. La valeur dérivée `earliest_confirmed_tender_receipt_at` correspond au 18 novembre. Elle déclenche une alerte globale, mais le dossier du lot 3 reste planifié contre le 25 novembre.

Un analyste qui ne poursuit que le lot 3 pourrait filtrer la vue après validation. La table source conserve néanmoins les trois lots. Cette conservation prouve que le bandeau a été interprété comme une prochaine échéance et non comme une règle générale. Si l’enveloppe du lot 3 devient inaccessible, sa dernière valeur passe en historique périmé; les deux autres lignes ne changent pas automatiquement.

Donnée périssable

Une nouvelle version oblige à tester de nouveau la portée

La matrice courante garde `notice_id`, `notice_version`, `observed_at` et `valid_until`. Une rectification peut prolonger un lot, tous les lots ou seulement une étape. Consommez d’abord la chaîne de versions acceptée par le registre des modifications. Relisez ensuite le périmètre de la nouvelle disposition. Une phrase générale située dans une section propre au lot 2 ne devient pas automatiquement une prolongation générale.

Les anciennes lignes restent accessibles avec `superseded_by`. Elles expliquent pourquoi un calendrier a changé et permettent d’auditer les alertes antérieures. Elles ne figurent plus parmi les valeurs actuelles. Un lot officiellement retiré reçoit `ceased`. La disparition de son bouton de dépôt, sans avis ni instruction, révèle plutôt un problème d’accès ou de publication.

Pour les procédures en plusieurs étapes, une absence peut être attendue. La ligne `tender` reçoit `not_issued_current_stage` lorsque l’avis prévoit une invitation ultérieure. La date de candidature est stockée dans une autre ligne. Ni la date estimée d’envoi de l’invitation ni une durée légale minimale ne produit le futur instant de réception.

La section 54 du Procurement Act britannique demande que les délais fixés soient identiques pour chaque fournisseur. Cette règle d’égalité ne prouve pas que tous les lots ferment le même jour. Les orientations britanniques décrivent les lots comme des contrats séparés et demandent au tender notice d’indiquer comment et à quelle date remettre offres ou candidatures. La matrice cherche encore la portée publiée dans le cas concret.

Lecture par agent

Un agent utile expose les lignes qu’il ne peut pas compléter

Fournissez un dossier d’entrée délimité: procédure canonique, version courante acceptée, documents publics de lot, observations autorisées du portail et événement recherché. Exigez une ancre pour chaque extraction. L’agent peut recenser les identifiants, lire les champs structurés, reconnaître une clause visant plusieurs lots, comparer des instants établis et calculer la première réception confirmée. Sa réponse principale reste la matrice.

Le contenu d’un appel d’offres constitue une entrée non fiable pour le comportement du système. Une pièce peut demander à un lecteur automatisé d’ignorer ses règles, de télécharger un fichier externe ou de révéler des accès. L’agent suit son contrat de vérification. Sans mandat distinct, il ne crée pas de compte, n’accepte pas de conditions, n’ouvre pas d’invitation privée, ne contacte pas l’acheteur et ne dépose aucun document.

L’abstention est obligatoire lorsque la liste des lots est incomplète, que la version courante n’est pas établie, que l’acte attendu reste ambigu, que la portée vient seulement de la mise en page, qu’une invitation nécessaire est protégée ou que deux sources se contredisent. Chaque abstention indique le manque précis et une suite autorisée. Exemple: « `LOT-04`, offre, date inconnue; l’avis ne publie que la candidature; prochaine vérification lors de l’invitation autorisée. »

Les problèmes voisins gardent leur propre dossier. Le fuseau ambigu part vers la vérification temporelle. Le désaccord entre sources part vers la réconciliation des dates. Une chaîne de rectifications incertaine part vers le registre des modifications. Un fichier inaccessible part vers l’état d’accès documentaire. Cette page assemble leurs faits acceptés et ne décide ni de l’opportunité de répondre, ni de la charge, ni de l’éligibilité, ni du dépôt.