New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maximum Extension Date #200
Comments
@timgdavies thanks Tim. My view is that it's a requirement across the EU, at least. Article 72 of the public procurement directive (2014/24/EU) permits a contract to be extended without a new tender process where this is provided for by clear, precise and unequivocal options in the original contract. It is almost universal practice to include such options - we talk, for instance, about a 5+2+2 contract, i.e. a five year contract with two two-year extension options. Hence a contract register may show the end date as it stands but it is perfectly legitimate to extend the contract beyond that date if a later date is permitted by an option clause in the original documentation. But a contract extended beyond the maximum end date might cause questions, since there are only limited circumstances where this is permissible. An extension beyond the maximum end date would generally be a new award. So my proposal would be to define maximum end date as being "the last contract end date permissible if all extension options set out in the contract originally awarded are used". I guess it would be needed in both tender and contract. Regards Al |
Thanks Al. Will look at the procurement directive and other EU data and see if we can get a proposal for this worked up. I'm noting also #171 on review dates. |
Thanks Tim. Picking up on #171, Keen also at some point to look at what it would take to convert our data into OCDS form (probably as a series of CSVs) as an exemplar. -----Original Message----- Thanks Al. Will look at the procurement directive and other EU data and see if we can get a proposal for this worked up. |
Looking at this, I would propose that we modify the period block so that it can include The definition of
QuestionsShould the guidance require that, in all cases where no extension is possible, this should be set to the same as endDate? What should users be able to infer from the absence of a maximumExtensionDate? Unless we require that it is always set the same as endDate when no extensions are possible, then it's absence could either imply:
And it would be hard to know which. |
Hi Tim I think a better definition might be "the latest date to which the contract may be extended according to the original contract documents". It may still be legal to extend beyond that - EU law permits extensions in certain cases, such as in unforeseen circumstances where the alternative would be impracticable. Regards Al -----Original Message----- Looking at this, I would propose that we modify the period block so that it can include startDate, endDate and maximumExtensionDate in all the instances where it appears. |
Is there any appetite for recording the full detail of extensions? Each extension should create at least one document to signify that the contracts has been extended, and so they're a valuable signifier to show whether buyers are publishing data properly and whether they're blindly extending contracts. In my mind extensions should have a one-to-may relationship, that covers the start and end dates of each extension, pk could be combination of tender_id and ext_increment. Duration could be optional, but would allow for automatic calculation of start and end dates.
|
@woodbine This does look important to me in terms of capturing the full details of a contracting process. Over in this issue there has been the suggestion to introduce a property called In OCDS terms then, the way to publish an extension would be a new entry in the I'll break-out a new issue for this. |
On the key issue of indicating maximum extension data I'm looking at extending the
Would this capture all the key data? It would be able to exist at tender, award and contract levels (and at the item/lot level in TED extended data). |
Hi Tim Stuff to think about.
Regards Al |
Would It seems to me there is a distinction we're dealing with here between 'hard' and 'soft' extension options that might be relevant when analysing data. We could consider an additional property which would capture this if there was a recognisable vocabulary already for talking about the distinctions between extension options. |
Hi Tim I think the difference is between exercising extension options set out in the original contract and extending the contract beyond those options. The latter is generally not good practice but equally in some circumstances is perfectly lawful, at least in some legal systems. The EU public contracts directive, for example, is quite specific about circumstances where such an extension is lawful. An authority which constantly used such extensions might well warrant further review. Maybe maxEnvisagedEndDate - "the last date for performance of the contract, allowing for the use of any extension options, set out in the contract when it was executed". |
We are having the same discussion in the case of Mexico City data. The issue is that is not an extension of the contract but there are some contracts that are multianual(multi-year). The same contract is used for different years (with a maximum of 4 years). We know if the contract is multianual in the budget part. We need some fields to know if this contract is multianual and how many years. We also need fields for knowing how much budget per year and what is the maximum value of the contract for all the years. |
The critical distinction here is being able to identify whether there is a) As Gabriella points out, there's also a question about whether there are There's also an historical perspective where we might want to investigate a The complexity comes when we have to a) define the nature of any extension To my mind, the simplest way of handling this would be to make a clear if we're really clever we should find a way of linking actual events to Regards, Ian On 4 February 2016 at 19:47, Gabriela Rodríguez Berón <
|
I've broken this out into a separate issue at #293. |
Ian I largely agree but think we need to be careful about regarding extensions as distinct, binary options. There is often such a binary option ("at the end of the initial term the contract may be extended by two years") but equally there may be a right to extend the contract by up to x years, in as many tranches as the parties agree. -----Original Message----- The critical distinction here is being able to identify whether there is a) As Gabriella points out, there's also a question about whether there are There's also an historical perspective where we might want to investigate a The complexity comes when we have to a) define the nature of any extension To my mind, the simplest way of handling this would be to make a clear if we're really clever we should find a way of linking actual events to Regards, Ian On 4 February 2016 at 19:47, Gabriela Rodríguez Berón <
— |
Agreed. Didn't mean to be over-simplistic, just feel we should make sure we Ian On 5 February 2016 at 12:30, Al Collier notifications@github.com wrote:
|
This is taken forward in #375 |
From @AlCollier in #199
At the moment we don't have 'Contract maximum extension date' in OCDS.
To introduce it we would need to identify:
The text was updated successfully, but these errors were encountered: