This proposal has been added as a GitHub issue, for inclusion in the version 2.02 development branch of the appropriate code repository: https://github.com/IATI/IATI-Codelists/issues/88

This item has been moved to the '2.02 Decimal Upgrade Proposals' forum for inclusion the upcoming decimal upgrade.

I would like to seek clarification on this change:

- There is no proposal to change the definition of "commitment", correct?  This remains "a firm, written obligation....to provide a specified amount of funds..."?  Since the definition of commitment seems to be quite unclear in the Activity Budgets discussion, I want to double-check that we are clear on the definition here and that we won't end up with an attribute for "tentative commitments" at some point.

- I want to make sure I understand how the codelist will work.  If it's an incoming commitment we would code it 11, while for an outgoing commitment we continue using code 2 "Commitment"?  Would it be clearer to rename 2 "Outgoing Commitment", or would that be too much trouble for what it's worth?

Yohanna, the definition of "commitment" will NOT change. It remains "a firm, written obligation....to provide a specified amount of funds...".  

This proposal has now been incorporated into a version 2.02 code repositories (see the above GitHub issue link for technical details). The relevant page on a development version of the 2.02 reference and documentation site is available to view here.

We welcome scrutiny on the implementation of this proposal and encourage the community to feedback and suggest solutions for any errors, omissions and problems. This should be done before Monday 7 December, when the process will commence to release version 2.02 as a live version of the IATI Standard. More information on the inspection phase is available here.

Herman I'm not sure I was in a position to do anything more than agree with you in a personal capacity (which I do) but Steven is right that we cannot make an embedded codelist (one which is defined by our own standard) applicable to earlier versions of the standard.

Rolf' while your suggestions are equally valid, we can't add mandatory fields in a decimal and given the important work going on in the Netherlands I am politically inclined to support Herman's proposal.

We currently already have ambiguity in the use of Commitments. I myself am guilty (in the past) of advising  NGOs to use "Commitment"  to mean an "Incoming Commitment" without necessarily specifying a provider-org. I think adding "Incoming Commitment" is a pragmatic best-bet. We will need to write some clear guidance so that publishers and users alike can get this to work.

This might be interesting particularly in humanitarian work, as commitments are often established early in humanitarian situations but funding does not flow for several weeks/months.

This proposal has been discussed amongst the IATI Technical Team following the end of the initial suggestion phase of the v2.02 upgrade.

The IATI Technical Team supports the principal of this proposal as a non-mandatory addition to version 2.02 only.  Further work is needed to clarify the required changes to the schema in order to implement this proposal, with further discussion encouraged in the meantime.

Please see below for the technical implementation that is suggested in the Version 2.02 - Formal Proposal:

Codelist addition: Transaction Type

• Add code:

• Code: 11

• Name: Incoming Commitment

Description: A firm, written obligation from a donor or provider to provide a specified amount of funds, under particular terms and conditions, reported by a recipient  for this activity.

I think it is perfectly possible to declare an incoming commitment already, by using the provider-org and receiver-org elements? I'd rather limit the number of codes to keep it manageable (for instance: 3-disbursement, 4-expenditure and 7-reimbursement leave room for differences in interpretation and implementation anyway).

We shouldn't change previous versions of the standard, or introduce a third-level digit to separate codelist updates from other (structural/semantic) updates of the standard. (That also depends on the life cycle/life span for versions of the standard, a separate discussion.)

Rolf,

using the same reasoning we could depreciate the Incoming Funds transaction. Nonetheless we have the Incoming Funds transaction and it is widely used. Therefore we should be consistent in the use of the transaction types, and also have the Incoming Commitment as a mirror image of the Incoming Funds transaction. Otherwise users of IATI data will have to use different logic for identifying Incoming Funds and Incoming Commitments. This will make the usage of the IATI data more complex than necessary.

Another compelling reason to add this transaction type is that the receiver-org and provider-org elments are not mandatory. This means that we can not always derive the direction of the flow of a commitment.

Regarding the IATI versions to aply this change to: I agree that it is not very neat to also introduce this new transaction type in pre 2.01 versions. Since this is a backward compatible change, I do not thing there is any harm in it though.

Hi Herman, I actually deleted that suggestion of removing the incoming funds code before I posted my comment :-)

I think we should indeed strive for more consistency:

• Either we have incoming funds, incoming commitments, but then we don't need "receiver-org" in those, nor do we need "provider-org" in disbursements, expenses, and such.
• Or we have disbursements and commitments, and the direction follows from having either the "receiver-org" or the "provider-org" (but again, not both at the same time).

Personally, I'd rather reduce code lists, but if separate codes are preferred, lets then make provider/receiver fields mandatory in the appropriate places too.