Skip to content
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

Closed
timgdavies opened this issue Mar 19, 2015 · 17 comments
Closed

Maximum Extension Date #200

timgdavies opened this issue Mar 19, 2015 · 17 comments
Assignees
Milestone

Comments

@timgdavies
Copy link
Contributor

timgdavies commented Mar 19, 2015

From @AlCollier in #199

does this accommodate:
Contract start date being some time after award (so contractPeriod doesn't start immediately)
Extension options built into contract from the beginning.

The standard for English local government ended up as:
Contract start date
Contract end date
Contract maximum extension date.

At the moment we don't have 'Contract maximum extension date' in OCDS.

To introduce it we would need to identify:

  • Other countries/contexts with this field
  • Whether it is needed on 'Tender', 'Award' or 'Contract' (or all of them)
  • The specific definition we should give it.
@AlCollier
Copy link

@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

@timgdavies
Copy link
Contributor Author

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.

@timgdavies timgdavies self-assigned this Mar 19, 2015
@AlCollier
Copy link

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-----
From: "timgdavies" notifications@github.com
Sent: ‎19/‎03/‎2015 21:30
To: "open-contracting/standard" standard@noreply.github.com
Cc: "Al Collier" collier.al@gmail.com
Subject: Re: [standard] Maximum Extension Date (#200)

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.

Reply to this email directly or view it on GitHub.

@timgdavies timgdavies added this to the After 1.0 milestone Jul 3, 2015
@timgdavies
Copy link
Contributor Author

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.

The definition of maximumExtensionDate would be:

  • "The latest date this period can be extended to under applicable regulations."

Questions

Should 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:

  • Unlimited extensions possible
  • No extensions possible

And it would be hard to know which.

@AlCollier
Copy link

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-----
From: "timgdavies" notifications@github.com
Sent: ‎03/‎07/‎2015 16:43
To: "open-contracting/standard" standard@noreply.github.com
Cc: "Al Collier" collier.al@gmail.com
Subject: Re: [standard] Maximum Extension Date (#200)

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.
The definition of maximumExtensionDate would be:
"The latest date this period can be extended to under applicable regulations."
Questions
Should 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:
Unlimited extensions possible
No extensions possible
And it would be hard to know which.

Reply to this email directly or view it on GitHub.

@woodbine
Copy link

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.

ContractID ext_increment ext_duration (mths) ext_start_date ext_end_date
xxxxxA 1 12 2015-12-31 2016-12-31
xxxxxA 2 12 2016-12-31 2017-12-31
xxxxxA 3 12 2017-12-31 2018-12-31
xxxxxB 1 24 2015-08-12 2017-08-12

@timgdavies
Copy link
Contributor Author

@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 extendsContractID which could be used to help model this.

In OCDS terms then, the way to publish an extension would be a new entry in the contract array which references the contract it is extending, and has explicit start and end dates on.

I'll break-out a new issue for this.

@timgdavies
Copy link
Contributor Author

On the key issue of indicating maximum extension data I'm looking at extending the contractPeriod object to include:

extensionPermitted as a boolean value;
maxExtensionDate as a date-time;
extensionDetails as a text field for description of any criteria relating to extending a contract

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).

@AlCollier
Copy link

Hi Tim

Stuff to think about.

  1. extensionPermitted is logically the same as "has break point" - need to think about how best to deal with this. In other words I might let a 4+4 deal or equivalently an eight year deal with a break point at four years.
  2. May be better called "HasExtensionOption" - since there are limited circumstances where a contract may legally be extended even when there was no such option in the original contract.
  3. Same issue with maxExtensionDate though I confess I can't think of a better name offhand!

Regards

Al

@timgdavies
Copy link
Contributor Author

hasExtensionOption looks like a good alternative to me.

Would maxExtentDate work in place of maxExtensionDate with a definition to the effect of: "the latest date at which delivery under this contract, or an extension of this contract, should take place".

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.

@AlCollier
Copy link

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".

@gabelula
Copy link
Contributor

gabelula commented Feb 4, 2016

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.

@woodbine
Copy link

woodbine commented Feb 4, 2016

The critical distinction here is being able to identify whether there is a)
a right to extend in advance of that option being chosen, b) whether or not
that extension option was exercised and c) when any extension option might
expire.

As Gabriella points out, there's also a question about whether there are
multiple extension options.

There's also an historical perspective where we might want to investigate a
history of persistent unexpected extension awards by a buyer.

The complexity comes when we have to a) define the nature of any extension
option, b) the nature of any extension taken and c) the effect that this
has on any contract value.

To my mind, the simplest way of handling this would be to make a clear
distinction between planned contractual options (extensions that can be
taken) and actual contractual events (extensions that have been taken).
Options are attributes defined at the point of contract award, (but may be
subject to amendment). Enacted extensions are events that occur within the
contract,

if we're really clever we should find a way of linking actual events to
options, for example, updating the budget according to the extensions
taken, but if we separate what is planned from what is executed, we should
be in good shape.

Regards,

Ian

On 4 February 2016 at 19:47, Gabriela Rodríguez Berón <
notifications@github.com> wrote:

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.


Reply to this email directly or view it on GitHub
#200 (comment)
.

@timgdavies
Copy link
Contributor Author

I've broken this out into a separate issue at #293.

@AlCollier
Copy link

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-----
From: "woodbine" notifications@github.com
Sent: ‎04/‎02/‎2016 20:57
To: "open-contracting/standard" standard@noreply.github.com
Cc: "Al Collier" collier.al@gmail.com
Subject: Re: [standard] Maximum Extension Date (#200)

The critical distinction here is being able to identify whether there is a)
a right to extend in advance of that option being chosen, b) whether or not
that extension option was exercised and c) when any extension option might
expire.

As Gabriella points out, there's also a question about whether there are
multiple extension options.

There's also an historical perspective where we might want to investigate a
history of persistent unexpected extension awards by a buyer.

The complexity comes when we have to a) define the nature of any extension
option, b) the nature of any extension taken and c) the effect that this
has on any contract value.

To my mind, the simplest way of handling this would be to make a clear
distinction between planned contractual options (extensions that can be
taken) and actual contractual events (extensions that have been taken).
Options are attributes defined at the point of contract award, (but may be
subject to amendment). Enacted extensions are events that occur within the
contract,

if we're really clever we should find a way of linking actual events to
options, for example, updating the budget according to the extensions
taken, but if we separate what is planned from what is executed, we should
be in good shape.

Regards,

Ian

On 4 February 2016 at 19:47, Gabriela Rodríguez Berón <
notifications@github.com> wrote:

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.


Reply to this email directly or view it on GitHub
#200 (comment)
.


Reply to this email directly or view it on GitHub.

@woodbine
Copy link

woodbine commented Feb 5, 2016

Agreed. Didn't mean to be over-simplistic, just feel we should make sure we
successfully separate what are essentially plans, from actual actions.

Ian

On 5 February 2016 at 12:30, Al Collier notifications@github.com wrote:

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-----
From: "woodbine" notifications@github.com
Sent: ‎04/‎02/‎2016 20:57
To: "open-contracting/standard" standard@noreply.github.com
Cc: "Al Collier" collier.al@gmail.com
Subject: Re: [standard] Maximum Extension Date (#200)

The critical distinction here is being able to identify whether there is a)
a right to extend in advance of that option being chosen, b) whether or not
that extension option was exercised and c) when any extension option might
expire.

As Gabriella points out, there's also a question about whether there are
multiple extension options.

There's also an historical perspective where we might want to investigate a
history of persistent unexpected extension awards by a buyer.

The complexity comes when we have to a) define the nature of any extension
option, b) the nature of any extension taken and c) the effect that this
has on any contract value.

To my mind, the simplest way of handling this would be to make a clear
distinction between planned contractual options (extensions that can be
taken) and actual contractual events (extensions that have been taken).
Options are attributes defined at the point of contract award, (but may be
subject to amendment). Enacted extensions are events that occur within the
contract,

if we're really clever we should find a way of linking actual events to
options, for example, updating the budget according to the extensions
taken, but if we separate what is planned from what is executed, we should
be in good shape.

Regards,

Ian

On 4 February 2016 at 19:47, Gabriela Rodríguez Berón <
notifications@github.com> wrote:

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.


Reply to this email directly or view it on GitHub
<
#200 (comment)

.


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub
#200 (comment)
.

@timgdavies
Copy link
Contributor Author

This is taken forward in #375

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants