Tender: Guarantees from the Bidder in order to preserve the Offer #900
Comments
|
Always was wondering why not to use requirements for this need? |
|
I think you are rigth, we can use that extension, but I'm going to open an issue to add "bid" to the relatesTo codelist. |
|
I don't think you should do it. 'relatesTo:tenderer' fits in this case - guarantees (both bid and contract execution) are requirements against tenderer, prescribes him to provide additional service. Its the same as a warranty requirement. Isn't it? |
|
I'm not sure. The tenderer example at the extension is about "Number of years the bidder has been trading" but in this case, the requirement is about the bid that the tenderer is doing, not about the tenderer it self |
|
Fare enough ) But let's take a look on this from the definition. It looks more like 'corporate commitment' rather than bids' attribute. On another hand, technically you will have requirementResponse related to guarantee requirement inside your bid. And, again, technically, all the criteria in this way or another related to bid. I mean - it's obvious ) |
|
I think @PaulBoroday is right with respect to all the requirements being about the bid, even if implicitly and/or indirectly. Regarding warranties, my understanding is that warranties are generally for items (e.g. Guarantees are different from warranties. For example, the buyer might require a bank guarantee for the value of the contract. If the supplier defaults on their obligation, the buyer can invoke the guarantee to get that value in cash. Such a guarantee is directly about the bid, as the value of the guarantee depends on the value of the bid, not on the tenderer/bidder or individual items. The question then is whether to just not set anything in
On the other hand, the disadvantages to not setting it to anything when it relates to the bid are:
I think the latter disadvantages are worse, so it seems reasonable to add the code to the codelist. cc @duncandewhurst since he wrote the extension. |
|
'Warranties' is not the main topic of this discussion, but once we touch it, my understanding a bit different. The main idea why to request any warranty is not to receive a sort of promise that motor will not fail within 3 years. No one can guarantee you that - your motor can fail tomorrow. Main idea is to have a suppliers' commitment that if supplied motor will fail during a certain period of time, this supplier will take responsibility (according to his commitment) to fix or replace this broken thing... |
|
Yes, I abbreviated the warranty description as it's not the subject here – it's more accurate to write it as you described. |
Field name changes: * Fix `type` to `documentType` * Rename `minimumLevel` to `minimum`, to be more flexible for future criteria, which might set minimum values, percentages, ratios, etc. * Rename `participationConditions` to `otherRequirements` * As mentioned by Giampaollo Sellitto in eForms/eForms#296 (comment), "participation criteria" or "participation conditions" are easy to confuse with "selection criteria" from a legal perspective. This is the reason ESPD uses "other criteria" and eForms uses "other requirements". * Rename `reservedTo` to `reservedParticipation`, mirroring `hasReservedExecution` * Rename `termsPerformance` to `performanceTerms`, to put words in regular order * Rename `hasPerformingStaffQualification` to `requiresStaffNamesQualifications`, for clarity * Rename `objectiveRulesCriteria` to `reductionCriteria`, see 2014/24/EU Article 65 * Rename `hasGuaranteeRequired` to `hasRequiredGuarantees`, to put words in regular order, and to allow multiple guarantees (like in some countries) open-contracting/standard#900 Modelling changes: * Change `selectionCriteria` to an object, with a `criteria` array as a sub-field, like with `awardCriteria` * Remove `isReservedToProfession` and rename `reservedToProfession` to `reservedExecution`, then use `hasReservedExecution` and `reservedExecution` for both sheltered employment programmes and professions * Move `hasRequiredGuarantees` from `otherRequirements` to `submissionTerms`, see eForms * Move `tendererLegalForm` from `otherRequirements` to `contractTerms`, see eForms Code changes: * Rename 'economicFinancial' to 'economic', to be consistent with the new `documentType.csv` code * Rename 'economicCriteriaSelection' to 'economicSelectionCriteria', to put words in regular order * Rename 'technicalCriteriaSelection' to 'technicalSelectionCriteria', to put words in regular order * Rename 'publicServiceMission' to 'publicServiceMissionOrganization' and 'shelteredWorkshops' to 'shelteredWorkshop', so that codes describe a singular organization type All forms: * Copy mappings across forms Other changes not related to this pull request: * Rename `maximumNumberParticipants` to `maximumParticipants` * Rename `durationRationale` to `periodRationale` * Fix `electronicInvoicing` to `electronicInvoicingPolicy` * Fix `electronicCatalogue` to `electronicCataloguePolicy` * Use "nearest earlier `date`" construction * Fix single quotes instead of backticks for code * Remove trailing whitespace
jpmckinney
added
the
Focus - Extensions
|
@yolile What did you end up doing in Paraguay? |
|
We used the requirements extension without setting the |
In Paraguay, the procuring entity have to define some information about the guarantees that the tenderers should provide. This guarantee is required to ensure that the offers made by the tenderers during the tender stage are kept if they are awarded.
The available data is:
Then, we have the data about the guarantees that the tenderers actually presented, this data is only available as structured data in the auctions, in traditional process we only have this data as documents, but the data that we have from the auction system is:
For model this, we could reuse the existing
Guaranteeobject that exists in the guarantees extension, changing theGuaranteeobject description to be more generic and less specific about that the Guarantee is for the contract. Also we need to update the obligations code list to include the type "preserveOffer", and also the type codelist to include policy, sworn statement and bank guarantee. Also we need to add adatefield and apercentfield. And maybe allow that the 'guarantor' doesnt have to be a OrganizationReference, so it doesnt have to be in the parties array.After that, maybe we can include the fields
"tender/requiredGuarantee"and"bid/guarantee"The legal definition of the guarantees can be found at Article 39 of the paraguayan public procurement law (page 38)
The text was updated successfully, but these errors were encountered: