EdiBuild Europe DRAFT eTendering FAQ

Références de la version

FAQ Revision K - 02/02/2009

Terminologie et notation

Les règles présentées dans ce document ont différents niveaux de préconisation : OBLIGATOIRE ou DOIT: ce niveau de préconisation signifie que la règle édictée indique une exigence absolue, RECOMMANDÉ ou DEVRAIT : ce niveau de préconisation signifie qu’il peut exister des raisons valables, dans des circonstances particulières, pour ignorer la règle édictée, mais les conséquences doivent être comprises et pesées soigneusement avant de choisir une voie différente, DÉCONSEILLÉ ou NE DEVRAIT PAS: ce niveau de préconisation signifie que la règle édictée indique une prohibition qu’il est toutefois possible, dans des circonstances particulières, de ne pas suivre, mais les conséquences doivent être comprises et le cas soigneusement pesé, INTERDIT ou NE DOIT PAS: ce niveau de préconisation signifie que la règle édictée indique une prohibition absolue. Ils doivent être interprétés comme décrit dans Internet Engineering Task Force (IETF) Request For Comments (RFC) 2119.1

Exemple - Une représentation d'une définition ou une règle. Les exemples sont informatifs.

[Note] - Commentaire explicatif, pour information.

[Rn] - Identification d'une règle dont le respect est exigé. Les règles sont normatives. Afin d'assurer la continuité dans les versions de la spécification, les numéros de règles qui sont supprimés ne seront pas affectés à nouveau, et les nouvelles règles se verront attribuer le numéro suivant le dernier utilisé, quel que soit leur emplacement dans le document.

Introduction

Voici quelques questions fréquemment posées et leurs réponses concernant l'implémentation du standard e-Tendering d'EdiBuild Europe. Le projet de standard, dérivé du standard e-Tendering de l'UN / CEFACT dont c'est une mise à jour comprend deux documents: InvitationToTenderDetails (détail de l'appel d'offres) et Tender (offre).


FAQ Index

Q1: Comment organiser les Breakdown Statement dans un appel d'offres (InvitationToTenderDetails) et dans une offre (Tender) ?

Q2: Quand un appel d'offres (InvitationToTenderDétails) a un Breakdown Statement Project Description et un Breakdown Statement Price List, quel(s) Breakdown Statement(s) doit-on mettre dans l'Offre ?

Q3: Comment fait-on le lien entre un article du descriptif quantitatif et l'article correspondant du bordereau des prix unitaires ?

Q4: Comment faites-vous pour identifier qu'un prix a été donné à titre indicatif seulement?

Q5: Si vous avez un certain nombre d'articles qui ont une description commune, comment les traiter ?

Q6: Comment utiliser les éléments Identifiant, PrimaryClassificationCode et AlternativeClassificationCode ?

Q7: Quelles sont les exigences pour les identifiants ?

Q8: Existe-t-il un format recommandé pour les noms de fichiers ebXML?

Q9: Comment utiliser la liste de codes EdiBuild Europe ?

Q10: Quelles sont les bonnes valeurs de code à utiliser pour InvitaitonToTenderDetailsBreakdownStatement / Type et TenderBreakdownStatement / Type (au niveau Breakdown Statement) ?

Q11: Où indiquer les prix ?

Q12: Comment gérer les prix forfaitaires ?

Q13: Comment indiquer si l'on demande ou ne demande pas de sous-total à un niveau particulier de la structure ?


Q1: Comment organiser les Breakdown Statement dans un appel d'offres (InvitationToTenderDetails) et dans une offre (Tender) ?

A: En attendant une mise à jour du standard pour avoir deux éléments explicitement différents, appliquer les règles R17, R18, R19 et R20 ci-dessous.

[R17] Pour l'appel d'offres (InvitationToTenderDetails), il est RECOMMANDE de créer deux Breakdown Statement, un pour la description du projet (ProjectDescription) avec les descriptions et les quantités, et un autre pour les prix (Price List Breakdown Statement).

[R18] Pour l'offre (Tender), il est RECOMMANDE d'avoir un Breakdown Statement Price List contenant les prix, et d'ajouter le Breakdown Statement "Project Description" de l'appel d'offres pour des informations complètes permettant de voir le contexte d'application de la liste de prix et de calculer le montant total de l'offre.

[R19] Pour le Breakdown Statement "Project Description" le nom TenderBreakdownStatement/Name DEVRAIT être "Descriptif Quantitatif Estimatif " ET le type TenderBreakdownStatement/Type DEVRAIT être "PRD".

[R20] Pour le Breakdown Statement "Price List" le nom TenderBreakdownStatement/Name DEVRAIT être "Bordereau des Prix Unitaires" ET le type TenderBreakdownStatement/Type DEVRAIT être "PRI".

Retour à l'index des FAQs

Q2: Quand un appel d'offres (InvitationToTenderDétails) a un Breakdown Statement Project Description et un Breakdown Statement Price List, quel(s) Breakdown Statement(s) doit-on mettre dans l'Offre ?

A: Voir les règles R4, R5 et R6 ci-dessous.

[R4] L'offre doit inclure le Breakdown Statement Price List (avec les prix renseignés) et le Breakdown Statement Project Description, tel que reçu dans l'appel d'offres, ce dernier pour permettant le calcul du prix total.

[R5] Les identifiants GroupedBasicWorkItem / IDs, ou ItemBasicWorkItem / IDs DOIVENT être présents et DOIVENT avoir les mêmes valeurs que les identifiants reçus dans l'appel d'offres (InvitationToTenderdétails).

[R6] Les descriptions DOIVENT être répétées dans les Breakdown Statement(s) d'offres pour permettre les vérifications.

Retour à l'index des FAQs

Q3: Comment fait-on le lien entre un article du descriptif quantitatif et l'article correspondant du bordereau des prix unitaires ?

A: Voir les règles R1 et R2 ci-dessous.

[R1] Dans le Breakdown Statement "Project description", le code ItemBasicWorkItem/TypeCode DOIT être "UPR" (de la liste de codes EBPRT).

[R2] Dans le Breakdown Statement Project Description, l'identifiant ItemBasicWorkItem/PriceListID DOIT être l'identifiant de l'ItemBasicWorkItem/ID correspondant du Breakdown Statement Price List ET ItemBasicWorkItem/ID/@schemeID DOIT être le TenderBreakdownStatement/ID du Breakdown Statement Price List.

Retour à l'index des FAQs

Q4: Comment faites-vous pour identifier qu'un prix a été donné à titre indicatif seulement?

A: Voir la règle R3 ci-dessous.

[R3] Dans le Breakdown Statement Project Description: Le code TotalCalculatedPrice/TypeCode DOIT être "INF" (de la liste de codes EBPRT).

Retour à l'index des FAQs

Q5: Si vous avez un certain nombre d'articles qui ont une description commune, comment les traiter ?

A: La solution la plus simple pour traiter des articles qui se réfèrent à une description commune est de mettre les descriptions communes au niveau des entêtes de section (GroupedWorkItems). Ainsi la description complète d'un article est la concaténation des sa propre description et de celle dont il dépend hiérarchiquement. Une autre solution consiste à référencer une description commune appartenant à un article de description commune "hors hiérarchie". Voir les règles R7, R8, R9 et R10 ci-dessous, qui s'appliquent dans les deux cas.

[R7] Dans un appel d'offres (détails), pour les ItemBasicWorkItem ou ItemGroupedWorkItem porteurs d'une description commune, le code TypeCode DOIT être "DES", de la liste de codes EBWIT, ce qui indique une description commune à tous les articles qui y font référence.

[R8] Dans un Invitation to Tender Details, pour les ItemBasicWorkItem, ou ItemGroupedWorkItem avec une description commune, le RequestCode DOIT être "NTP" pour "ne pas indiquer de prix". "

[R9] Un ItemBasicWorkItem, ou ItemGroupWorkItem avec un prix se référant à une description commune DOIT avoir un code WorkItemTypeCode "RGD", qui indique que la description comprend une description commune.

[R10] Un ItemBasicWorkItem, ou ItemGroupedWorkItem avec un prix se référant à une description commune DOIT avoir un identifiant ReferenceID dont la valeur est celle de l'ID de l'article ou de l'entête de section de description commune auquel il se réfère.

Retour à l'index des FAQs

Q6: Comment utiliser les éléments Identifiant, PrimaryClassificationCode et AlternativeClassificationCode ?

A: L'identifiant (ID) est un identifiant interne utilisé pour référencer un article ou section dans un Breakdown Statement. Cet identifiant n'est pas destiné à être vu par l'utilisateur. Le PrimaryClassificationCode devrait définir la structure du projet. Par défaut, la structure est basée sur la hiérarchie du Bill of Quantities. L'AlternativeClassificationCode peut être utilisé pour indexer un Breakdown Statement selon autant d'autres structures que nécessaire, par exemple pour faire le lien avec une bibliothèque externe.

[R23] Pour afficher une référence d'article ou de section à un utilisateur, il est RECOMMANDE d'utiliser le PrimaryClassificationCode et NON l'identifiant.

[R24] Le PrimaryClasificationCode DEVRAIT définir la structure du projet. Par défaut, la structure du projet est basée sur l'arborescence du Bill Of Quantities et le PrimaryClassificationCode DEVRAIT être cohérent par rapport à cette arborescence.

[R25] L'AlternativeClassificationCode PEUT être utilisé pour indexer un Breakdown Statement selon autant de structures que nécessaire.

Retour à l'index des FAQs

Q7: Quelles sont les exigences pour les identifiants ?

A: Ils sont utilisés pour identifier l'article de l'appel d'offres ou de l'offre par rapport à celui qui est enregistré dans une base de données. Les Règles R11 et R12 ci-dessous s'appliquent.

[R11] L'identifiant ID doit être unique pour l'émetteur et mentionner le code de la liste d'identifiants à laquelle il se réfère.

[R12] L'identifiant, dans la liste d'identification à laquelle il se réfère, DOIT être unique.

Retour à l'index des FAQs

Q8: Existe-t-il un format recommandé pour les noms de fichiers ebXML?

A: Le nommage est fait par l'émetteur du fichier. Une convention de nommage a été proposée, concaténant les paramètres suivants: Idconsult : identifiant de la consultation, par exemple sa référence au BOAMP (il est conseillé de ne pas dépasser 12 car). Numéro de lot: à ajouter le cas échéant après l’identifiant Idconsult, sous la forme LotNN Numéro de variante: à ajouter le cas échéant après l’identifiant Idconsult ou le numéro de lot, sous la forme VarianteNN Idsoum : identification du soumissionnaire, pour les fichiers de la soumission seulement (il est conseillé de ne pas dépasser 12 caractères). VXY= V+n° de version ZZZ= extension (. XML pour les documents ebXML). Voir les règles R13, R14 et R15 ci-dessous.

[R13] Il est RECOMMANDE d'utiliser cette convention de nommage en attendant un format convenu à l'échelle internationale.

[R14] Les différents paramètres composant le nom de fichier DEVRAIENT être séparés par un tiret bas ( _ ) à l'exception de l'extension de fichier qui doit être précédée par un point (.).

[R15] Il est RECOMMANDE que le nom du fichier, à l'exclusion de l'extension du fichier, soit indiqué dans l'InvitationToTenderDetailsDocument/ID et le TenderDocument/ID.

Retour à l'index des FAQs

Q9: Comment utiliser la liste de codes EdiBuild Europe ?

A: Un fichier contenant toutes les listes de codes EdiBuild est inclus dans le Pack des schémas XML .

[R16] Dans certains cas, il existe plusieurs listes de codes qui peuvent être utilisés. En conséquence, pour tous les éléments de code, les attributs "list Name" et "List Agency Name" DOIVENT être renseignés.

Retour à l'index des FAQs

Q10: Quelles sont les bonnes valeurs de code à utiliser pour InvitaitonToTenderDetailsBreakdownStatement / Type et TenderBreakdownStatement / Type (au niveau Breakdown Statement) ?

A: Voir le tableau ci-dessous.

Code values to use at the Breakdown Statement level (only yellow parts are mandatory)
Case 1: Project description and Price list (including item descriptions) are in separate Breakdown Statements
Case 2: Project description and Price list are merged in a single Breakdown Statement
 
Document Type Breakdown Statement Type Code (Code List EBBQT) Tendering Request Code (Code List EBREQ) Information Status (NOTE SUPERSEDED ELEMENT. NOW ASSOCIATED ABIE. NO CODE LIST.]
List of common code values PRD (Project description) TBR (To be returned) Quantified and priced
PRI (Price list) NTR (Not to be returned) Quantified and unpriced
PDP (Project description and price list) TBQ (To be quantified) Not quantified and unpriced
  NTQ (Not to be quantified) Not quantified and priced
  TBP (To be priced)  
  NTP (Not to be priced)  
 
InvitationToTenderDetails (Case 1) PRD (Project description) TBR (To be returned) or NTR (Not to be returned) (default value) and Quantified and unpriced (default value)
TBQ (To be quantified) or NTQ (not to be quantified) (default value) and Not quantified and unpriced
NTP (Not to be priced) (default value)  
PRI (Price list) TBP (To be priced) Not quantified and Unpriced (default value)
InvitationToTenderDetails (Case 2) PDP (Project description and Price list) TBP (To be priced) Unpriced (default value), quantified; (default value) or Not Quantified
 
Tender (Case 1) Project description should not be returned    
PRI (Price list)   Priced
Tender (Case 2) PDP (Project description and Price list)   Priced
 
Coded values are available in the Code Lists spreadsheet included in the EdiBuild Europe e-Tendering Bundle.
  Yellow = mandatory
The code values at Grouped Work Item or Basic Work Item levels are needed only if different from the upper level values.

Retour à l'index des FAQs

Q11: Où indiquer les prix ?

A: Les prix unitaires vont dans les éléments UnitCalculatedPrice/ChargeAmount et les prix totaux vont dans l'élément TotalCalculatedPrice/ChargeAmount au niveau du Breakdown Statement.

Retour à l'index des FAQs

Q12: Comment gérer les prix forfaitaires ?

A: Un prix forfaitaire peut être indiqué dansl'unité de mesure et le type de prix. Si le soumissionnaire est tenu de soumettre un prix forfaitaire pour un article alors l'unité de mesure dans la description de l'objet sera "LS" (cas 1). Si l'article a une quantité et une unité de mesure (par exemple m2) mais que le soumissionnaire souhaite indiquer que son prix pour cet article est une somme forfaitaire (plutôt qu'un prix unitaire), et n'est donc pas dépendant de la quantité, il indique cela en mentionnant le prix comme forfaitaire (cas 2). Ces deux cas sont traités selon les règles R21 et R22 ci-dessous.

[R21] Cas 1: Dans l'InvitationToTenderDetails Breakdown Statement, ItemBasicWorkItem/TotalQuantity DOIT être à 1 ET ItemBasicWorkItem/TotalQuantity/@unitCode = "LS". Dans le Tender Breakdown Statement l'UnitCalculatedPrice/ChargeAmount DOIT être à 0 (zéro) ET TotalCalculatedPrice/ChargeAmount doit être le montant forfaitaire.

[R22] Cas 2: dans l'InvitationToTenderDetails Breakdown Statement ItemBasicWorkItem/TotalQuantity devrait être la quantité demandée ET ItemBasicWorkItem/TotalQuantity/@unitCode être l'unité de mesure. Dans le Tender Breakdown Statement l'UnitCalculatedPrice/ChargeAmount DOIT être 0 (zéro) ET TotalCalculatedPrice/ChargeAmount DOIT être le montant forfaitaire ET TotalCalculatedPrice/TypeCode DOIT être "LSI" (Code de la Liste EBPRT).

Retour à l'index des FAQs

Q13: Comment indiquer si l'on demande ou ne demande pas de sous-total à un niveau particulier de la structure ?

A: Utiliser la valeur de code "STR" ou "NST" (de la liste de codes EBREQ) dans l'élément RequestCode.

Retour à l'index des FAQs