_NB: picking up on discussions that are here: http://support.iatistandard.org/hc/en-us/articles/214390586 - with @Herman @rolfkleef @YohannaLoucheur @bill_anderson @JohnAdams _
As we know, the code “Incoming Commitment” was added to 2.02 (but not to earlier versions of the standard, as @Herman originally proposed). My understanding is that one purpose of this is to enable publishers to be clear about the commitments they have from others - and to not use the Incoming Funds code to declare this.
This leaves the Commitment code. @YohannaLoucheur asked:
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?
This didn’t seem to get discussed in the original thread.
Looking across the standard. there seems to be a slight ambiguity in terms of the relationship between the Commitment transaction and a “total budget” of an activity. IATI Guidance states:
Commitment (code2)- the total agreed budget for the activity.
The actual codelist definition for Commitment seems to be different in approach:
A firm, written obligation from a donor or provider to provide a specified amount of funds, under particular terms and conditions, for specific purposes, for the benefit of the recipient.
In short, I think there are two uses of Commitment, around IATI land. Publishers may do either (or both in some cases)
- We’re committing this value to this activity aka the total-budget
- We’re committing this value to this partner
The first use case is supported by the fact that publishers are not encouraged to use the `budget`` element to declare the total budget of an activity (and a total-budget element does not exist in the activity standard - only the org standard)
The second use case supports the “full-chain” transparency, referenced by @Herman:
Since the current standard only supports the ‘Commitment’ as a transaction type, it is impossible to distinguish between incoming and outgoing commitments. Without this element full chain transparency is therefore not possible.
And so - here could be our difficulty. If the same code is wide open to two use cases, we face difficulties in getting datasets to work together, potentially.
To sum: Renaming (or clarifying) Commitment to Outgoing Commitment may start to make things clearer for implementation, although we should also be minded that this code is in widespread use.
(In trying to pick up and type up this discussion, it does seem to make the case for a total-budget
element in the activity standard, or perhaps some work on the budget/@type
attribute/codelist)