in-effect: when does it become true?

[JoepDemey]

Hi, we are having discussions about the in-effect field and when exactly it becomes true.

The documentation states: True, if this IIA is or once was in effect - that is, it has been signed, and the partners are (or were) following its rules. False, if this IIA is a draft or proposal only (and it hasn't been agreed on). This flag allows to differentiate between actual agreements, and the proposed agreements. (IIAs API allows to peek on both.)

So, just to be clear: what do these 2 things mean?

• it has been signed: does this mean signed by the owner, or approved by the partner?
• the partners are (or were) following its rules: does this mean the partner approved it? Or does it mean the partner (also?) has a linked version of this IIA? That is also approved?

So far, we were setting in-effect true once our partner approved our version, but we have partners that claim in-effect can only be true when both partners have an IIA that are linked and are both approved.

[demilatof]

in-effect can only be true when both partners have an IIA that are linked and are both approved

I'm for this solution, because only when there is a mutual approval the partners have to follow its rules, not before: "and the partners are (or were) following its rules". What I think it's wrong is the sentence: "IIAs API allows to peek on both". Could someone explain me what IIAs API allow me to choose to peek on the actual agreement or on the proposed agreement?

Anyway, with the current APIs, this element is useless and brings only misunderstanding.

• Before the first mutual approval it is must set to false (always).
• When there is the first mutual approval, I take a snapshot before approving (and not after), therefore I save an IIA without "in-effect" set to true.
• After the first mutual approval, it must be always set to true. Useless, if I've recorded a mutual approval I even know that it is (or it has been) in effect.

[janinamincer-daszkiewicz]

Flag in-effect was introduced to IIAs API version 0.1.0 posted in 2016-12-20. In 2020-02-26 IIA Approval API was introduced. In-effect is equivalent to IIAs mutually approved. In that sense it is redundant and could be removed.

Does anyone see any additional use for this flag?

[pabloop]

Forgive me for rescuing this thread,

Relatively recently we moved our IIAs API to production and we are working on the development of versions 6.3.0/7.0.0 and we have a couple of doubts with this in-effect field.

If we did not misunderstand, to pass the tests prior to putting the API into production, this field should be false when the agreement was being negotiated through the EWP network. When the agreement was approved by both partners it should be marked as true.

1) In API version 6.2.0 we are getting through IIAS GET agreements that are not even mapped and already come with this field set to true. Is this correct or is this a misinterpretation by the partner?

2) Regarding the move to version 6.3.0. When we reopen a mutually approved agreement, should this field be set to false again until the modifications on the agreement are approved by both with the meaning "with changes and therefore not currently in effect"? (in case we have to revert to the last mutually approved agreement we understand that it would revert to true as well as if the changes on the agreement are again approved by both).

Thanks, Pablo University of Granada

[kamil-olszewski-uw]

Ad 1. This is partner's misinterpretation. Ad 2. IIA is "in-effect" if it is or ever was in use. So you shouldn't revert in-effect back to false.

By the way, it should be noted that the in-effect flag is only business information and no technical actions on our side should depend on its value on the partner's side.

[jiripetrzelka]

What if the IIA has been agreed by e-mail and mobility has already been realized in 2021/22 or 2022/23 but partner has not approved it yet or has not provided their copy yet? From the business perspective, the IIA is already in effect. From the EWP perspective, it is not. Do I understand it correctly that in this case the in-effect should be false, despite it having been in effect from the business perspective?

[demilatof]

What if the IIA has been agreed by e-mail and mobility has already been realized in 2021/22 or 2022/23 but partner has not approved it yet or has not provided their copy yet? From the business perspective, the IIA is already in effect. From the EWP perspective, it is not. Do I understand it correctly that in this case the in-effect should be false, despite it having been in effect from the business perspective?

"In effect" is only a useless parameter, something that once was useful but later brings only confusion, because replaced by other functionalities. They are aware of this, nevertheless we still have this garbage in the specifications. With version 7 we could have the opportunity to get rid of it, but it is still present.

[jiripetrzelka]

What if the IIA has been agreed by e-mail and mobility has already been realized in 2021/22 or 2022/23 but partner has not approved it yet or has not provided their copy yet? From the business perspective, the IIA is already in effect. From the EWP perspective, it is not. Do I understand it correctly that in this case the in-effect should be false, despite it having been in effect from the business perspective?

@kamil-olszewski-uw Could you please specify whether the business level perspective is more important or the technical level perspective (having mutual approval) when setting this element to true or whether you consider to remove this element?

[kamil-olszewski-uw]

We are considering removing this element. But as long as it exists, I think a technical perspective should be taken. Although we should not make any automatic system functions dependent on in-effect, setting this attribute to true in the case of IIAs without mutual EWP approval may lead to misunderstandings.

[demilatof]

We are considering removing this element.

When? Hopefully already with version 7...

[janinamincer-daszkiewicz]

No, version 7 is closed.