Tender: Margin of preference (price coefficients)

[jpmckinney]

Related to #443.

For example, the Kyrgyz e-GP system includes a web form with a “benefits domestic bidders” boolean field that is associated with a number field for the percentage-wise preference for domestic prices as well as a free-text note field.

We compared this example to giving a price preference to a bid that has a guarantee/warranty on the item. After working through different scenarios, we came up with this sort of structure (field names and codelist values may need more work, and not all fields are needed for Kyrgyz):

{
  "priceCoefficientGroups": [
    {
      "id": 1,
      "title": "Benefits domestic bidders",
      "description": "Domestic bidders receive a 20% price preference.",
      "type": "domestic",
      "priceCoefficients": [
        {
          "coefficient": 0.8
        }
      ]
    },
    {
      "id": 2,
      "title": "Product warranty",
      "description": "A minimum product warranty of 1 year is required for all bids. Warranties of 2 years receive a 15% advantage. Warranties of 3 years or more receive a 30% advantage.",
      "type": "warranty",
      "relatedLots": ["lot-1", "lot-2"],
      "relatedItems": ["item-1"],
      "priceCoefficients": [
        {
          "coefficient": 1,
          "minimum": 1,
          "maximum": 1
        },
        {
          "coefficient": 0.85,
          "minimum": 2,
          "maximum": 2
        },
        {
          "coefficient": 0.7,
          "minimum": 3
        }
      ]
    }
  ]
}

We introduce a PriceCoefficientGroup object to avoid repeating the title, description, etc. when we have multiple related coefficients, like coefficients for no warranty, warranty of 1 year, warranty of 2 years, etc.

In the above example, I use discrete numbers of years (1, 2, 3). If we want to allow continuous, non-overlapping ranges, we would need properties like exclusiveMinimum and exclusiveMaximum. However, it may be overly complicated to model this numeric information, so it may be simpler to replace the min/max fields with a option string to describe the available options in the submission form. We should collect some evidence from real systems to see how this is implemented.

[timgdavies]

Could this not be modelled using requirements/features (which still need separation into two rather than one extensions I believe), with an indication of when the feature has an influence on price vs. quality scoring?

With either that option, or the above, we will need to think about how to make this maximally comprehensible to the user - and how this information should be displayed and analysed.

[jpmckinney]

Price coefficients are distinct from requirements or criteria (there's no question of 'satisfying' a price coefficient), but yes, there is overlap in the modelling. 'Criterion' in CCCEV is defined as "something used as the basis for making a judgement or decision, e.g. a requirement set in a public tender or a condition that has to be fulfilled for a public service to be executed."

Whether the bidder is domestic is not, itself, the basis for making a judgment – it's not a requirement or a condition to be fulfilled. It does, however, give a price advantage if true.

The tender notice may require a 1 year warranty, but whether the warranty is longer (like 3 years) is of no relevance to determining whether the bid meets the criteria and, on its own, has no impact on the decision. Longer warranties may, however, give a price advantage.

I think it's a bit monolithic or incoherent to try to squeeze all possible price coefficients into a CCCEV-based model. We could have a link to a requirement from a PriceCoefficientGroup.

[duncandewhurst]

Draft data from Belarus includes a preference field on the Bid object, which indicates the discount applicable to the bid for the purposes of evaluation, for example a 15% discount is applied to domestic bids. Helpdesk feedback suggested renaming the field to evaluationDiscount

[PaulBoroday]

For MTender we are planning to use the following approach:

Conversions

As soon as not only quantitative criteria has to be included into the Contract Notice but also - applicable options and weights, a separate extension has to be applied to allow CA to include all the conversions needed for future qualification and evaluation.

Conversions - is a tool that allows describing used conversions and its applicable coefficients.

• to describe used conversions and its applicable coefficients either as a list of precise values or as a mathematical formula for calculation of the value of particular coefficient in this particular case (depending on the value received within requirementResponse related to specific requirement) to be applied
• to relate each conversion used (together with coefficients) with used criteria or targets (where applicable)
• to include applicable options to used criteria or observations for targets

True/false requirement and its coefficients of conversion

The simple criterion that requires only true/false answer can be used by CA. For example - if currently submitting EO is a domestic bidder, his offer will get a ratio that increases the advantage of its price by 20%:

{
  "criteria": [
    {
      "id": "001",
      "title": "Benefits",
      "description": "Benefits domestic bidders",
      "source": "tenderer",
      "relatesTo": "tenderer",
      "requirementGroups": [
        {
          "id": "001-1",
          "requirements": [
            {
              "id": "001-1-1",
              "title": "Is Economic operator is domestic bidder?",
              "description": "",
              "dataType": "boolean"
            }
          ]
        }
      ]
    }
  ]
}

Using ocds_requirements_extension we can describe this criterion as such. But using conversions we can also describe applicable coefficients:

{
  "conversions": [
    {
      "relatesTo": "requirement",
      "relatedItem": "001-1-1",
      "rationale": "Domestic bidders receive a 20% price preference",
      "coefficients": [
        {
          "value": true,
          "coefficient": 0.8
        },
        {
          "value": false,
          "coefficient": 1
        }
      ]
    }
  ]
}

So if EO will respond that his company is a domestic bidder, using cross-reference through requirement_id we can extract an applicable coefficient - 0.8

---

Requirement with a predefined set of coefficients of conversion for a specific criterion value

The criterion that requires a precise answer with detalization can be used by CA. For example - when minimum product warranty of 1 year is required for all bids but warranties of 2 years receive a 15% advantage and warranties of 3 years or more receive a 30% advantage:

{
  "criteria": [
    {
      "id": "002",
      "title": "Product warranty",
      "description": "A minimum product warranty of 1 year is required for all bids. Warranties of 2 years receive a 15% advantage. Warranties of 3 years or more receive a 30% advantage.",
      "source": "tenderer",
      "relatesTo": "item",
      "relatedItem": "1",
      "requirementGroups": [
        {
          "id": "002-1",
          "requirements": [
            {
              "id": "002-1-1",
              "title": "A minimum product warranty of 1 year is guaranteed",
              "dataType": "boolean",
              "expectednValue": true
            },
            {
              "id": "002-1-2",
              "title": "The number of years for proposed product warranty",
              "dataType": "integer",
              "minValue": 1,
              "maxValue": 3
            }
          ]
        }
      ]
    }
  ]
}

Using ocds_requirements_extension we can describe this criterion as such where EO is required to confirm that he guarantees at least 1 year of product warranty (002-1-1) but also specify a precise number of years for such guarantee for the proposed product (002-1-2).

And using conversions we can also describe applicable coefficients:

{
  "conversions": [
    {
      "relatesTo": "requirement",
      "relatedItem": "002-1-2",
      "rationale": "Number of years for product guarantee",
      "description": "",
      "coefficients": [
        {
          "value": 1,
          "coefficient": 1
        },
        {
          "value": 2,
          "coefficient": 0.85
        },
        {
          "value": 3,
          "coefficient": 0.7
        }
      ]
    }
  ]
}

Depending on EOs response we will have an applicable coefficient for future conversion.

---

Requirement with a formula-based (calculated) coefficients of conversion for a specific criterion value

For the same criterion described above (product warranty) using conversions we can also describe coefficients for conversion not like a predefined set of values but as a mathematical formula that will be used to calculate applicable value:

{
  "conversions": [
    {
      "relatesTo": "requirement",
      "relatedItem": "002-1-2",
      "rationale": "Number of years for product guarantee",
      "description": "",
      "coefficients": [
        {
          "formula": "1.15-(value/10)*15"
        }
      ]
    }
  ]
}

Using mentioned formula and having a value for option inputed by EO withing his bid we can calculate applicable value for the coefficient of conversion:

• for 1 year: 1.15 - (1/10) * 15 = 1
• for 2 years: 1.15 - (2/10) * 15 = 0.85
• for three years: 1.15 - (3/10) * 15 = 0.7

As you can see - the result is the same

---

Requirement with available options to choose

Additionally procuriosity_conversions covers a following: ability to include an applicable options into used requirement. Such an approach allows prescribing more precise ranges of expected values together with specific coefficients of conversion.

For example: if CA requires EO to have at least one Google certified specialist on his board but ready to grant EO with additional advantage if such EO has more than one guy:

{
  "criteria": [
    {
      "id": "003",
      "title": "Capacity",
      "description": "Minimum qualification requirements",
      "source": "tenderer",
      "relatesTo": "tenderer",
      "requirementGroups": [
        {
          "id": "003-1",
          "requirements": [
            {
              "id": "003-1-1",
              "title": "At least one Google certified specialist on-board",
              "dataType": "boolean",
              "expectedValue": true
            },
            {
              "id": "003-1-2",
              "title": "Number of Google certified staff",
              "description": "",
              "dataType": "integer",
              "minValue": 1,
              "options": [
                {
                  "maxValue": 3,
                  "title": "Up to three specialist"
                },
                {
                  "maxValue": 5,
                  "title": "Up to five specialists"
                },
                {
                  "minValue": 6,
                  "title": "More han five specialists"
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

And the conversion will be the following:

{
  "conversions": [
    {
      "relatesTo": "requirement",
      "relatedItem": "003-1-2",
      "rationale": "Number of Google certified staff",
      "description": "",
      "coefficients": [
        {
          "minValue": 1,
          "coefficient": 1
        },
        {
          "minValue": 4,
          "coefficient": 0.99
        },
        {
          "minValue": 6,
          "coefficient": 0.98
        }
      ]
    }
  ]
}

Coverage for targets

As shown in examples above, it is the following construction used instead of using requirementReference from ocds_requirements_extension.

    "relatesTo": "",
    "relatedItem": "",

This is done for a purpose: in the same way, as it used for requirements, conversions could be used for another one attribute of contracting process that used to describe indicative or precise forecast of procurement - targets.

Using relatesTo-approach we can use both options and conversions for targets as well.

For example, CA is going to buy 1000 cars during some period. Of course its much more convenient for him to buy it from 'one hand' but what if there is no one on the market how can deliver such quantity of cars? (yes - it goes to the lots, this is just an example :). In that case, CA can describe options, available for this target together with the conversion which will be applied for the lower offered quantity of cars:

{
  "targets": [
    {
      "id": "annualNeed",
      "title": "Annual need",
      "description": "The annual need",
      "observations": [
        {
          "period": {
            "startDate": "2015-01-01T00:00:00Z",
            "endDate": "2015-12-31T23:59:59Z"
          },
          "measure": 1000,
          "unit": {
            "id": "NC",
            "name": "car"
          },
          "options": [
            {
              "measure": "800"
            }
          ]
        }
      ]
    }
  ]
}

And the conversion will be:

{
  "conversions": [
    {
      "relatesTo": "target",
      "relatedItem": "annualNeed",
      "rationale": "Indexing of the increase in total cost of ownership",
      "description": "",
      "coefficients": [
        {
          "coefficient": 1.15
        }
      ]
    }
  ]
}

So we can see that EO who offers less than 1000 cars will be accepted for evaluation but with 15% lower offer advantage (just due to the increasing total cost of ownership for CA).

A similar approach could be applied where CA needs to tie his spendings with the achieved level of KPIs by supplier while implementing the contract (e.g. energy efficiency services) or to achieve the best value for money under 'quality-only' procedures.

@jpmckinney would be great to hear your opinion about all this and do you think it deserves to be marked as 'Focus - Extensions' and moved forward?

Full release-scheme available here

[jpmckinney]

@PaulBoroday Thank you for your thorough examples! We will have a look at the extension shortly.

[jpmckinney]

I made an initial review of the technical correctness of the extension. Once corrected, I'll do a closer review of the modelling. https://bitbucket.org/procuriosity/procuriosity_conversions/issues/1/typos-and-other-errors

[PaulBoroday]

Thanks, @jpmckinney ! I believe everything is sorted so far. Repo moved to Github

Also thinking to move “options” our from this draft to another one. Maybe this extension could be improved: https://github.com/open-contracting-extensions/ocds_options_extension/blob/master/release-schema.json ?

UPD: #691 (comment)

[jpmckinney]

UNCITRAL glossary defines:

Term	Definition	Reference
Margin of preference	A technique applied in the evaluation of submissions that permits the procuring entity to accord a more favourable treatment to some suppliers or contractors or goods (usually domestic suppliers or contractors or domestically produced goods) in comparison with others. When the difference in price (or price combined with quality scores) between the submissions from a favoured group (or with respect to favoured goods) and the overall lowest-priced or most advantageous submission falls within the range of the margin of preference, a submission from the favoured group (or with respect to favoured goods) is ascertained as successful in accordance with the rules concerning the calculation and application of a margin of preference that are to be set out in the legislation of the enacting State. For the explanation of the terms “evaluation”, “goods”, “domestic suppliers or contractors” and “domestically produced goods”, see ## 27, 35, 22 and 23 above. For the explanation of the terms “submission”, “procuring entity” and “supplier or contractor”, see ## 83, 62 and 85 below.	N/A

[yolile]

Is this kind of covered/overlaped by the award criteria breakdown extension?

[jpmckinney]

Sometimes, there's a two step process. First, award criteria are used to assign each bid a score. Then, if multiple scores are within a "margin of preference" (UNCITRAL term) of the lowest bid, then price coefficients are applied to determine the winner. The simplest implementation is to assign a coefficient of 0 (or 0.0̅1), i.e. if local bidders are within the margin of preference of the lowest bid, then the lowest bid among local bidders wins. If these coefficients were applied before the award criteria, then local bids would always win.

[yolile]

Makes sense. open-contracting/ocds-extensions#132 suggest adding a "weight" field to requirements, but as per your comment #574 (comment) we don't want to model this under requirements (e.g., by setting the weight to 0 as part of the Criterion object).

[jpmckinney]

As noted in the UNCITRAL definition:

the rules concerning the calculation and application of a margin of preference that are to be set out in the legislation of the enacting State

In other words, if there is a margin of preference, it will generally not be disclosed in each contracting process (similar to how a standstill period is typically universal and therefore not disclosed in each contracting process).

This issue also discusses the weighting of individual requirements. Modelling individual requirements has not achieved consensus, so it is better to continue working on those issues in the requirements extension. So, closing here.