Cotizaciones | Request for quotes [ES] [EN]

[antonioherrera]

Text in english below

Versión en español

Asunto

En México, antes de iniciar un procedimiento de contratación es obligatorio realizar cotizaciones (entre al menos tres posibles proveedores) cuando se trata de adjudicaciones directas. Sin embargo, también es posible realizar estas cotizaciones en procedimientos de licitación pública e invitaciones a cuando menos tres personas. Las cotizaciones son un proceso que se realiza en la etapa de planeación antes de publicar cualquier convocatoria.

Los “Lineamientos técnicos generales para la publicación, homologación y estandarización de la información de las obligaciones establecidas en el título quinto y en la fracción IV del artículo 31 de la Ley General de Transparencia y Acceso a la Información Pública, que deben de difundir los sujetos obligados en los portales de Internet y en la Plataforma Nacional de Transparencia” (página 108), contemplan la obligación de publicar cierta información sobre las cotizaciones.

En particular, los lineamientos contemplan la publicación de la siguiente información:

• Nombre de los posibles proveedores que participan en las cotizaciones.
• Monto de las cotizaciones.
• Campo sí/no para indicar si se realizan cotizaciones.

Es por ello que, con el objetivo de homologar el Estándar de Datos de Contrataciones Abiertas (EDCA) con las obligaciones de transparencia en México, y por ende, con los Sistemas de Portales de Obligaciones de Transparencia (SIPOT) administrados por el Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI), consideramos necesario desarrollar una extensión que contemple la información relacionada con las cotizaciones.

En este contexto, la Secretaría de la Función Pública (SFP) considera fundamental la inclusión de atributos adicionales a los establecidos por la normativa en transparencia, debido a que el sistema CompraNet contempla la generación de otra información que puede servir como base para entender mejor los procesos de cotizaciones.

En concreto, los datos que pueden ser utilizados del sistema CompraNet son los siguientes:

• Texto que describe el objeto que se quiere cotizar
• Periodo en el que se espera recibir cotizaciones
• Ítems que serán cotizados
• Nombre de los posibles proveedores invitados a cotizar
• Nombre de los posibles proveedores que enviaron una cotización
• Descripción de la cotización
• Fecha en la que se realiza la cotización
• Ítems que se cotizaron
• El valor total de lo cotizado
• La vigencia de la cotización

Propuesta

Agregar un arreglo al objeto de planeación (planning). Este arreglo debe contener los siguientes atributos:

• Planning {object}
  • hasQuotes? (boolean)
  • requestsForQuotes [array]
    • requestForQuotes {object}
      • id (string, integer)
      • quoteRequestText (string)
      • quoteRequestPeriod {object}
        • Period
      • items [array]
        • Item
      • vendors [array]
        • OrganizationReference
      • quotes [array]
        • Quote {object}
          • id (string, integer)
          • sender {object}
            • OrganizationReference
          • description (string)
          • date (date)
          • items [array]
            • Item
          • value
            • Value
          • validityPeriod
            • Period

Pasos a seguir

Para indicar soporte a esta propuesta usa los botones de +1 / -1 y la sección de comentarios, si te opones a la propuesta justifica tu postura.

---

English version

Issue

In Mexico, before starting a contracting process, it's mandatory to make quotes (among at least three possible suppliers) when the contract is meant to be awarded to a single supplier without competition. However, it is also possible to make these quotations in others procurement methods. The request for quotations is a process that is done in the planning stage before publishing any notice.

The "General technical guidelines for the publication, homologation and standardization of the information of the obligations established in title five and in section IV of article 31 of the General Law on Transparency and Access to Public Information, which must be disseminated by the subjects obliged in the Internet portals and in the National Transparency Platform" (page 108), consider the mandatory publication of certain information on quotation's process.

In particular, the guidelines include the publication of the following information:

• Name of the possible suppliers participating in the quotations.
• Amount of the quotations.
• Field yes / no to indicate if quotes are made in the procurement process.

Thus, with the aim of match the Open Contracting Data Standard (OCDS) with the transparency obligations in Mexico, and therefore, with the Transparency Obligations Portals System (SIPOT) administered by the National Institute of Transparency, Access to Information and Protection of Personal Data (INAI), we consider necessary to develop an extension that includes the information related to the quotation process.

In this context, the Public Service Secretariat (SFP) considers the inclusion of additional attributes to those established by the regulations in transparency, since the CompraNet system consider the generation of other information that can serve as a basis for a better understanding of the quotations processes.

Specifically, the data that can be obtained from the CompraNet system are the following:

• Text describing the object to be quoted
• Period in which it is expected to receive quotations
• Items that will be quoted
• Name of the possible suppliers invited to quote
• Name of potential suppliers who submitted a quote
• Description of the quotation
• Date when the quota
• Items that were quoted
• The total value of the quoted
• The validity of the quote

Proposal

Add an array to the planning object. This array must contain the following attributes:

• Planning {object}
  • hasQuotes? (boolean)
  • requestsForQuotes [array]
    • requestForQuotes {object}
      • id (string, integer)
      • quoteRequestText (string)
      • quoteRequestPeriod {object}
        • Period
      • items [array]
        • Item
      • vendors [array]
        • OrganizationReference
      • quotes [array]
        • Quote {object}
          • id (string, integer)
          • sender {object}
            • OrganizationReference
          • description (string)
          • date (date)
          • items [array]
            • Item
          • value
            • Value
          • validityPeriod
            • Period

[timgdavies]

Thanks you for such a clear extension description and proposal. I've worked through a number of steps to review the proposal, noted below:

(1) Checking for any existing extensions or approaches to meet the need described

As a general principle, we always look in OCDS to see where existing structures can be re-used, so I have evaluated against your initial description whether the model of the bids extension could be appropriate to also model quotes at the planning stage. My conclusion is that there is a substantial difference between the fields collected there for bids, and the fields that would be collected for a quote. That supports the model above of using a new object for request for quotes.

The second issue I've considered is whether this information should be in tender rather than planning. There is an outstanding issue open for consideration for the next upgrade of OCDS to rename the tender object to initiation and to allow an array of values, to recognise that not all contracts are initiated with a tender. However, this is a longer term change to OCDS, and would only form part of a 2.0 (non backwards compatible) upgrade, and so does not help solve the immediate problem of publishing quote data.

Conclusion: There is a good case for an extension here.

(2) Reviewing the proposed extension and terminology

I've considered whether the suggested terminology above is consistent with other uses in OCDS, and whether it is intuitive/self-describing wherever possible

The sketch makes good re-use of existing OCDS building blocks. In a few cases I had questions on the chosen property names:

• quoteRequestText - in general we don't include Text as part of an OCDS property name. I can see in this case there might be a justification for doing so. I would recommend however the alternative pattern consistent with other OCDS objects would be to have a title and description field under requestForQuotes which would contain the information that should be displayed to those invited to quote.

• quoteRequestPeriod - this could be just period rather than quoteRequestPeriod, as (a) in flattened versions it will appear as requestForQuotes/0/period and in structured versions the nature of the period could be inferred from the parent object. However, this is a minor point, and I think is a stylistic choice.

• vendors - we don't use the term vendors elsewhere in OCDS. Consider whether suppliers or invitedSuppliers could be used (as this might also be mirrored by a role in the parties array)

• sender - this is also a novel term in OCDS, and slightly ambiguous (a person might send a quote on behalf of a supplier). Could supplier be used here?

Thanks once again for the great work on this. I look forward to seeing the draft extension develop.

[antonioherrera]

Thank you Tim for taking your time in this extension.

I was considering all your questions and I tried to solve them:

• As you noted, the justification to have a "text" field rather than a title and description was because it refers the exact text that is included in the request for quotes. However, I don't think there is strictly necessary to name it quoteRequestText, and I agree in adding a title field.

• I agree in removing the prefix in requestForQuotesPeriod for simplicity. However, I think there should be a different name for the period when the quote is valid. There is any comments with validityPeriod?

• I agree in renaming the vendors to invitedSuppliers in order to distinguish from suppliers section. In the same way, I think we could use issuingSupplier as the person or organization who send a quote. The only question here is how can we divide these parties (the invited supplier and the possible supplier that sent a quote) in the partyRoles codelist, should we name them with different names?

We are working in the development of the draft extension and we will be back with a worked example,

Thank you very much for all your comments.

[JArielMG]

Worked example:

{
  "definitions": {
    "RequestForQuotes": {
      "title": "Request for quotes",
      "description": "A request for quote (RFQ) is a type of procurement solicitation in which a buyer asks outside vendors to offer an estimated price for a particular goods or services.",
      "type": "object",
      "required": [
        "id"
      ],
      "properties": {
        "id": {
          "title": "Request ID",
          "description": "A request for quote (RFQ) is a type of procurement solicitation in which a buyer asks outside vendors to offer an estimated price for a particular goods or services.",
          "type": [
            "string",
            "integer"
          ],
          "minLength": 1,
          "versionId": true
        },
        "title": {
          "title": "Title",
          "description": "The request for quotes title.",
          "type": [
            "string",
            "null"
          ]
        },
        "description": {
          "title": "Description",
          "description": "The text sent to the possible suppliers in order to participate in the quotation process. ",
          "type": [
            "string",
            "null"
          ]
        },
        "period": {
          "title": "Period",
          "description": "The period between the date when the request for quotes was made and the end date to receive the quotes.",
          "$ref": "#/definitions/Period"
        },
        "items": {
          "title": "Items to be quoted",
          "description": "The goods and services to be quoted, broken into line items wherever possible. Items should not be duplicated, but a quantity of 2 specified instead.",
          "type": "array",
          "items": {
            "$ref": "#/definitions/Item"
          },
          "uniqueItems": true
        },
        "possibleSuppliers": {
          "title": "Possible suppliers",
          "description": "A list of possible suppliers asked to send quotes.",
          "type": "array",
          "items": {
            "$ref": "#/definitions/OrganizationReference"
          }
        },
        "quotes": {
          "title": "Quotes",
          "description": "A list of quotes received from possible suppliers.",
          "type": "array",
          "items": {
            "$ref": "#/definitions/Quote"
          }
        }
      },
      "patternProperties": {
        "^(description_(((([A-Za-z]{2,3}(-([A-Za-z]{3}(-[A-Za-z]{3}){0,2}))?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-([A-Za-z]{4}))?(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}|[0-9][A-Za-z0-9]{3}))*(-([0-9A-WY-Za-wy-z](-[A-Za-z0-9]{2,8})+))*(-(x(-[A-Za-z0-9]{1,8})+))?)|(x(-[A-Za-z0-9]{1,8})+)))$": {
          "type": [
            "string",
            "null"
          ]
        }
      }
    },
    "Quote": {
      "title": "Quote",
      "description": "A quote is a fixed price offered by a possible supplier for particular goods or services.",
      "type": "object",
      "required": [
        "id"
      ],
      "properties": {
        "id": {
          "title": "Quote ID",
          "description": "A local identifier for this quote, unique within this block.",
          "type": [
            "string",
            "integer"
          ],
          "minLength": 1
        },
        "possibleSupplier": {
          "title": "Possible supplier",
          "description": "A list of possible suppliers asked to send quotes.",
          "type": "array",
          "items": {
            "$ref": "#/definitions/OrganizationReference"
          }
        },
        "description": {
          "title": "Description",
          "description": "Quote description. Terms and conditions for the quote.",
          "type": [
            "string",
            "null"
          ]
        },
        "date": {
          "title": "Quote date",
          "description": "The date of the quote. This is the date when the quote was received.",
          "type": [
            "string",
            "null"
          ],
          "format": "date-time"
        },
        "items": {
          "title": "Items quoted",
          "description": "The goods and services quoted, broken into line items wherever possible. Items should not be duplicated, but a quantity of 2 specified instead.",
          "type": "array",
          "minItems": 1,
          "items": {
            "$ref": "#/definitions/Item"
          }
        },
        "value": {
          "title": "Value",
          "description": "The total value of this quote.",
          "$ref": "#/definitions/Value"
        },
        "quotePeriod": {
          "title": "Quote period",
          "description": "The period in which this quote is valid.",
          "$ref": "#/definitions/Period"
        }
      },
      "patternProperties": {
        "^(description_(((([A-Za-z]{2,3}(-([A-Za-z]{3}(-[A-Za-z]{3}){0,2}))?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-([A-Za-z]{4}))?(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}|[0-9][A-Za-z0-9]{3}))*(-([0-9A-WY-Za-wy-z](-[A-Za-z0-9]{2,8})+))*(-(x(-[A-Za-z0-9]{1,8})+))?)|(x(-[A-Za-z0-9]{1,8})+)))$": {
          "type": [
            "string",
            "null"
          ]
        }
      }
    },
    "Planning": {
      "properties": {
        "hasQuotes": {
          "title": "Has quotes?",
          "description": "A true/false field to indicate whether any quotes were received during the planning process.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "requestsForQuotes": {
          "title": "Requests for quotes",
          "description": "A list of requests for quotes related to the planning process.",
          "type": "array",
          "items": {
            "$ref": "#/definitions/requestForQuotes"
          }
        }
      }
    }
  }
}

I would welcome views on this suggested modelling.

[jpmckinney]

@antonioherrera I did an initial review of the extension, and @JArielMG merged the changes. Would you like this extension to be added to the extension registry as a community extension?

[antonioherrera]

Sure, go ahead.

[jpmckinney]

While the request for quotes might occur as part of what is named the planning stage locally, in the context of OCDS, this type of behavior would generally occur during the initiation/tender stage (the planning stage in OCDS would correspond to a behavior like deciding what to request quotes for).

The EU and other jurisdictions also have defined processes for awarding contracts without competition (in which case no prior notice is published).

While a distinction can be drawn between a bid and a quote, I'm not clear that the types of quotes here are so substantially different from bids that the same object couldn't satisfy both use cases. The Quote object adds quotePeriod (validity period), items, and description, all of which would make sense of the Bid object. The fields that are unique to the Bid object (documents, status) would also make sense on the Quote object.

The RequestForQuotes object is not dissimilar from the Tender object, either.

As such, I will leave this as a local extension, though it might inform changes to the Bids extension.

[yolile]

If we use bids for quotes, how can one distinguish between the bids made during the "request for quotes" stage and the actual bids at the tender stage? (for tenders with competition). Comparing the tender/tenderPeriod/startDate with the bids dates,?

[yolile]

And also, note that "marketStudies" is a document type disclosed as part of the planning process. As I understand, requests for quotes in open tenders are for informing the future tender and items' referential prices (so, part of the market studies). So, at least for open tenders, I'm not sure if the request for quotations is indeed part of the tender and not planning.

[jpmckinney]

You'll have to explain the full procedure, preferably with an example from a real jurisdiction, because otherwise I don't have enough information to comment on the model.

In many jurisdictions, a request for quotes is just a specific type of invitation to bid (i.e. the nature of the goods/services is precisely known, and the buyer just wants a price), or it's the first step of a two-stage process (e.g. buyer knows what they want but not what it costs, so they only invite quotes that fall below a threshold to prepare a full bid). In the second case, it's just an efficiency measure, so that potential suppliers don't need to prepare dozens of pages of content if their price is already too high. See, for example: https://www.investopedia.com/terms/r/request-for-quote.asp

[jpmckinney]

For the broader problem of how to distinguish submissions made in a first stage vs those made in a second stage, I think that's #906. (At present, we pretty much never see disclosure of second-stage bids.)

[jpmckinney]

In terms of adding more detail to planning processes, I think our only relevant open issue is #794 (very broad).

If a publisher performs a market study, and if this market study involves requesting prices from potential suppliers, and if this information is publishable, then we can open a new issue to discuss how to model that.

[yolile]

The Mexico case explained in this issue description is the real case, but it also applies to other Latam countries.

If a publisher performs a market study, and if this market study involves requesting prices from potential suppliers, and if this information is publishable, then we can open a new issue to discuss how to model that.

Yes, that is the Mexican case. (and the same in other Latam countries but without data publication). For Mexico, this was resolved with their local extension. But I'm bringing this up again because it could also apply to Chile soon. If that is the case, I will open a new issue then.

But it is important to clarify that the use case this issue wanted to model was about requesting quotes for market analysis.

[jpmckinney]

Aha. Yes, let's open a new issue, but without calling it request for quotes, because that means different things in different jurisdictions.

In the model, we'll want to align with existing tender and bid models where possible. We should also be informed by what information Chile or others can actually publish. If we try to standardize about 15 fields (like in Mexico's extension), but we only have evidence for 5 of those fields, we'll end up closing the issue as unresolvable due to lack of evidence.

[yolile]

For reference, in Paraguay, this information is gathered via emails to suppliers (before the tender publication), requesting to fill out a form which then is published as a document within the tender. Email text example: "This quote will be used to average the reference price to be used in the tender process, it will not be taken into account as a bid in the tender process, nor does it represent any commitment for your company."

Example of the document published here see ("Antecedentes de Estimación de Costos"), so no structured information to publish in this case.

[jpmckinney]

I see a familiar name there ;)

I see the phrases "cost estimation background" and "background for calculating referential prices", which are clearer.

Although it's not machine-readable, we can see name, identifier (RUC), date issued (submitted), amount, currency, VAT included (see #817).

For whatever reason, although the sentence before the key-value table is "The validity of this quote will be for a period of 6 months", one response has "24 month term".

In any case, I'm not sure we need to model both the cost and period of a quote – considering the buyer in this case was explicit about the desired period.

[jpmckinney]

Noting that in #1522 there was a question (bullet 3) about adding a role for tenderers who participate in and/or submit to market consultations.

[jpmckinney]

I created #1625

[jpmckinney]

Just to follow-up: This was partly resolved in open-contracting-extensions/ocds_bid_extension#45 to close open-contracting/ocds-extensions#94

More recently, as discussed in #1649 and closed by #1669, we use the word "quote" as a potential form of bid.