Appeal information | Información sobre las inconformidades

[alexter42]

This issue is under consideration for an extension to OCDS 1.1
(Texto en español abajo)

Issue

In Mexico, appeals are a legal contesting instrument that bidders can present against certain acts related to both the tender and the award processes.
Appeals can be presented in the following cases:

1. To the call for tenders and clarification meetings.
2. When a selective procurement method is chosen.
3. In the proposal submission and opening event.
4. Tender cancellation.
5. With regard to the acts and omissions of the procuring entity.
6. The tender results.

Additional information can be found at:

• Law on Acquisitions, Leases and Services of the Public Sector , Articles 65 - 76.
• Law of Public Works and Related Services, Articles 83 - 94.

Proposal

A new appeal extension definition could contain an array of appeals; each appeal should have the following attributes :

• Identifier
• Name of the organization or person presenting the appeal.
• Act that is being appealed ( the value should be extracted from codelist).
• The reception date of the appeal.
• Rationale of the appeal.
• Description of the appeal.
• Receiver organization data.
• Public authority data.
• The resolution for the appeal
• Resolution document

To fully implement the aforementioned data (e.g in a user interface), the attributes must also produce the following values:

• Number of appeals received
• Number well-founded appeals
• Number baseless appeals

Worked example

{
"appeals": [
                {
                      "title": ,
                      "rationale": "",
                      "description": "",
                      "appealObject": "",
                      "publicAuthority": "",
                      "appellant": "",
                      "receiverOrganization": "",
                      "receptionDate": "",
                      "hasLegalBasis": "",
                }
           ]
}       

Engagement

Please indicate support or opposition for this proposal using the +1 / -1 buttons or a comment. If opposing the proposal, please give clear justifications, and where possible, make an alternative proposals.

---

Asunto

En México, las inconformidades son un medio de impugnación que pueden presentar los interesados o licitantes contra los actos de los procedimientos de acuerdo a la Ley de Obra Pública y Servicios Relacionados con las mismas
La inconformidad se puede presentar durante la etapa de licitación y adjudicación en referencia a lo siguiente:

1. La convocatoria a la licitación, y las juntas de aclaraciones.
2. La invitación a cuando menos tres personas.
3. El acto de presentación y apertura de proposiciones.
4. La cancelación de la licitación.
5. Los actos y omisiones por parte de la entidad convocante.
6. El fallo.

Info adicional:

• Ley de Adquisiciones, Arrendamientos y Servicios del sector Público , Artículos 65 - 76.
• Ley de Obras Públicas y Servicios relacionados con las mismas, Artículos 83 - 94.

Actualmente, el Estándar de Datos de Contrataciones Abiertas no contempla dichos medios de impugnación.

Propuesta

Añadir un arreglo de inconformidades al objeto tender y al objeto award con detalles de cada inconformidad.

Añadir un objeto inconformidades cuyo atributo sea un arreglo de objetos inconformidad

Los atributos del objeto inconformidad:

• Identificador
• Título
• Nombre de la organización o persona que presenta la inconformidad
• Acto que se impugna (codelist)
• Fecha en que se presenta la inconformidad
• Motivos de la inconformidad
• Descripción de la inconformidad
• Instancia que recibe la inconformidad
• Ente público que desarrolla el procedimiento de contratación que se impugna

Adicionalmente al dar seguimiento a la inconformidad se deben generar los siguientes datos:

• Resolución a la inconformidad
• Número de inconformidades recibidas
• Número de inconformidades fundadas
• Número de inconformidades infundadas
• Documento de resolución

Ejemplo propuesto

{
"appeals": [
                {
                      "title": ,
                      "rationale": "",
                      "description": "",
                      "appealObject": "",
                      "publicAuthority": "",
                      "appellant": "",
                      "receiverOrganization": "",
                      "receptionDate": "",
                      "hasLegalBasis": "",
                }
           ]
}       

---

Also known as (aliases):

Según @juanpane, en Paraguay esto se conoce como Protesta

[timgdavies]

There is some similarity here to the discussion of complaint information in #205

@alexter42 @juanpane In your view, are complaint, protesta and appeals all the same concept?

If so - this is a very good issue for us to move something that could be a core OCDS extension in future.

The next steps for that would be to compare the work in #205 with the modelling suggested above, to see whether they can be brought closer together.

[julijahansen]

We have been reviewing this issue alongside the complaint information issue #205 and we propose the following extension model to capture both appeal and complaint information:

Proposed model:

• objections array will sit inside the tender object and will be used to capture information relating to complaints, appeals and claims
• We will add 2 new roles to the parties.roles open codelist - "objector" (for the organization submitting an objection) and "objectionReceivingBody" (for the organization receiving and dealing with the objection)
• For documents.documentType field, which is an open codelist, there is already an option for "complaints", so that can be used to denote documents relating to complaints. In addition options for "appeals", "claims", "complaintResolution", "appealResolution", "claimResolution" can be added to this open codelist

Schema example:

{
	"objections": [{
		"id": "",
		"title": "",
		"description": "",
		"status": "Will be a closed codelist and include the following values: draft, submitted, received, answered, pending, invalid, declined, resolved, cancelled.",
		"type": "Will be an open codelist and can include values like: complaint, appeal, claim.",
		"objectionTo": "Will be a closed codelist and will include the following values: initiation, award, contract.",
		"relatedAward": "Will capture the id of the award that this objection relates to (if relevant).",
		"relatedContract": "Will capture the id of the contract that this objection relates to (if relevant).",
		"dateSubmitted": "",
		"dateReceived": "",
		"dateCancelled": "",
		"dateAnswered": "",
		"documents": [{
			"id": "",
			"documentType": "This is an open codelist and the following values can be used: complaints, appeals, claims, complaintResolution, appealResolution, claimResolution.",
			"title": "",
			"description": "",
			"url": "",
			"datePublished": "",
			"dateModified": "",
			"format": "",
			"language": ""
		}],
		"resolution": {
			"type": "Will be a closed codelist and include the following values: invalid, declined, resolved.",
			"description": "",
			"date": ""
		},
		"relatedObjection": "For example current appeal can be linked to a preceding complaint, so this field will be used to capture that preceding complaint id."
	}]
}

Questions:

1. Would "objections" work as a colective term for appeals, complaints and claims?
2. From the translators' perspective, is "objections" a relatively simple term to translate into e.g. different localizations of Spanish (e.g. Mexico, Uruguay, Paraguay etc.)?
3. Would terms like "objector" and "objectionReceivingBody" be appropriate to use in this context? Would they be easy to translate/localize?
4. For resolution.type - are "invalid", "declined", "resolved" appropriate values for this field or is there anything else that is missing?

Please also let us know your general thoughts, comments and questions about this proposed model. Is there anything crucial that is missing? Should anything be changed?

[timgdavies]

This looks good. I wonder if we can include documents just at the level of the individual objection, rather than also in resolution. If we did include it in resolution we would need to have resolution.id, as in order to allow flattening of data to work, the parent of any array of objects needs to have an id property.

I did want to just run a thought-experiment test of a quick alternative model based on understanding objections/appeals essentially as a series of messages between objector and 'reviewBody', such that you might have:

{
  "objections": [
    {
      "id": "1",
      "type": "objection",
      "status": "rejected",
      "lastUpdated": "2017-11-09T09:00:00Z",
      "relatedAward": "",
      "relatedContract": "",
      "releasedObjection": "",
      "updates": [
        {
          "id": "1",
          "date": "2017-07-01T14:03:34Z",
          "status": "submitted",
          "sender": {
            "id": "GB-COH-1235567",
            "name": "Company X"
          },
          "recipient": {
            "id": "GB-GOV-1234567",
            "name": "Government procurement review team"
          },
          "title": "The tender process was not followed.",
          "description": "The tender process was not fairly followed. See attached report for details of the problems."
        },
        {
          "id": "2",
          "date": "2017-07-02T17:00:00Z",
          "status": "accepted",
          "sender": {
            "id": "GB-GOV-1234567",
            "name": "Government procurement review team"
          },
          "recipient": {
            "id": "GB-COH-1235567",
            "name": "Company X"
          },
          "title": "Objection received",
          "description": "Your objection has been received and assigned a case officer."
        },
        {
          "id": "2",
          "date": "2017-09-15T11:45:00Z",
          "status": "resolved",
          "sender": {
            "id": "GB-GOV-1234567",
            "name": "Government procurement review team"
          },
          "recipient": {
            "id": "GB-COH-1235567",
            "name": "Company X"
          },
          "title": "Objection upheld.",
          "description": "The objection was upheld. "
        }
      ],
      "documents":[
        {
            "id": "1",
            "documentType": "complaint",
            "title": "Complaint supporting details",
            "description": "The timestamp of this matches the sending timestamp above, so ",
            "url": "http://example.com/files/complaint.pdf",
            "datePublished": "2017-07-01T14:03:34Z",
            "dateModified": "2017-07-01T14:03:34Z",
            "format": "application/pdf",
            "language": "en"
          },
          {
            "id": "2",
            "documentType": "complaintResolution",
            "title": "Resolution report",
            "description": "This report details resolution of the complaint",
            "url": "http://example.com/files/resolution.pdf",
            "datePublished": "2017-09-15T11:45:00Z",
            "dateModified": "2017-09-15T11:45:00Z",
            "format": "application/pdf",
            "language": "en"
          }
      ]
    }
  ]
}

In this, the array of updates contains the date of each status change, removing the need for dateSubmitted, dateReceived etc. and allowing a flexibility in the workflow states an objection might move through.

However, I'm not sure if this all goes too far towards an abstract model, and makes it hard to clearly express to publishers the key information about objections that they should publish.

For me this raises a question between flexible modelling, and the standard functioning to encourage disclosure of particular appeals and complaints information.

[julijahansen]

Thanks for your comments @timgdavies! I have removed documents from the resolution object, as you suggested, so now it only exists at the objections level. Thank you for also proposing an alternative model using the updates array. I do agree that it allows for more flexibility, however as you mentioned it might not encourage as much disclosure of complaint/appeal information due to the absence of specific fields with a clear purpose, e.g. dateSubmitted, dateReceived, resoluton object. Also from data querying perspective I think the first model would allow for easier and more efficient querying, as the fields are clearly labelled and you could for instance see which date relates to which event from the field name, rather than having to flatten the updates array, then look at the status field to see what that particular date relates to. So as I write this I think I am overall leaning more towards the first model approach.

[julijahansen]

@juanpane and @ColinMaudry, wanted to get your thoughts on this proposal

[ColinMaudry]

Sure... But I need to check with my contact a Ministry of Finances, I don't know well how appeal work in France. I'll come back to report here.

[chrisalexsmith]

I have recently been doing some research on the complaints system in Albania and have observed the following:

1. A fee is charged payable by the supplier for submitting a complaint - this also happens in other countries and in the case of Albania it apparently raises revenue of Euro 1mn per year. I guess it would be refundable if the complaint is upheld.

Public Procurement Commission Report 2016-English.pdf
2. The Public Procurement Commission in Albania produces an annual report that includes detailed statistical analysis of complaints received e.g. number of complaints by procuring entity, by category of goods, tender value etc and outcome e.g. Rejected or upheld, tender cancelled as a result etc etc.

3. Complaints can either be processed in a 1 or 2 stages i.e.
   In first instance the supplier should submit their complaint directly to the procuring entity.
   If the matter is not satisfactorily resolved between the supplier and the procuring entity, the supplier can lodge an appeal with the Public Procurement Commission.

Additionally, I note that the procurement legalisation normally defines the period during which a complaint can be lodged and in the case of Albania there is an issue as complaints are submitted and it seems processed after the expiry of the deadline.

[jpmckinney]

Related: MAPS includes these quantitative indicators which can potentially be calculated from OCDS data, if appeals information were included:

• number of appeals (in % of contracts awarded)
• number (and percentage) of enforced decisions
• outcome of appeals (dismissed; decision in favour of procuring entity; decision in favour of applicant) (in %)

Time-frame based:

• appeals decisions posted within the time frames specified in the law (in %)
• appeals resolved within the time frame specified in the law/exceeding this time frame/unresolved (Total number and in %)
• share of appeals decisions posted on a central online platform within timelines specified in the law (in %)

[jpmckinney]

There is good work here on proposing a model, but no subsequent validation or engagement by the broader community since 2017. Without that, the evidence for the proposal doesn't seem strong enough on its own to bring it forward.

Closing in favor of #598 #205 where I'll mention this issue.