IATI Consultations Archive

Live discussions and consultations can be found at discuss.iatistandard.org.

Modify recipient-country and recipient-region : merge?

Avatar
Bill Anderson
Follow

Current IATI rules state that EITHER recipient-region OR recipient-country should be used. The rules also state that when multiple countries or regions are reported a percentage split should be reported which must add up to 100%. This is unsatisfactory as an activity may well include both regional and country-level spending. Here are four possible solutions.

  1. Allow for both existing elements to be used with the percentage split shared between them.
  2. Allow for the reporting of region and country at transaction as well as activity level
  3. Deprecate recipient-region and recipient-country and replace them with a single recipient element and a single recipient code list. (Given that there is no single globally agreed list of region definitions this approach is challenging)
  4. Deprecate recipient-region and recipient-country and replace them with a single recipient element. Add a new @type attribute to allow for the distinction between code lists.

A combination of 1. and 2. may be the best solution?

 

 

Have more questions? Submit a request

7 Comments

Date Votes
  • 0
    Avatar
    Mark Brough

    The standard guidance should encourage the identification of specific countries (and multiple countries if relevant) rather than higher-level, more aggregate regions. Of course, it will not be possible to identify specific countries in all cases.

    1. makes sense, but it's worth checking how many organisations are using both (e.g. to state "Tanzania" and "East Africa", where this means "100% in Tanzania" rather than "50% in Tanzania and 50% in East Africa"). If no/few organisations are using this then the costs of adjustment are likely to be low.

    2. agree with this suggestion.

    3. and 4. are significantly breaking changes so should be avoided.

  • 0
    Avatar
    Bill Anderson

    Iteration 1 - Proposal 1 - Include recipient-country and recipient-region at transaction level.

    The proposal is to add

    • transaction/recipient-country
    • transaction/recipient-region

    so that a more accurate breakdown of resource allocation can be made (rather than using a percentage split at activity level)

  • 0
    Avatar
    Bill Anderson

    Iteration 1 - Proposal 2 - Combined usage of recipient-country and recipient-region

    • Current guidance advising use of only one or other of these elements should be reversed
    • recipient-region should only be used to indicate that the region as a whole is a recipient, not as an added description to a named recipient-country
    • if both elements are used percentages must be reported and they should add up to 100% across all recipient- elements
  • 0
    Avatar
    Herman van Loon

    One addition to avoid inconsistencies: when countries/regions are specified on the transaction level, they should NOT be specified on the activity level . The other way around: when countries/regions and percentages are specified on the activity level: they should not be specified on the transaction level. This should in my opnion be part of the guidelines.

    The country/region percentages on activity level should in my opinion NOT be depreciated, since individual transactions are in practice often not earmarked to a specific country or region.

  • 0
    Avatar
    Bill Anderson

    Thanks Herman

    • I agree and will add to the proposal's guidance
    • There is no plan to remove or deprecate at activity-level

    Bill

  • 0
    Avatar
    Yohanna Loucheur

    The four solutions proposed seem reasonable. We agree with Herman Van Loon's comment and are glad that the activity level won't be deprecated.

    As for challenge with Option 3 (no single globally agreed list of region definitions), our suggestion would be to use the DAC list of regions as this list is official, currently in donor systems, and maps to the DAC recipient code list for regional/continent level reporting.

     

  • 0
    Avatar
    IATI Tech Team

    Note that the proposal is now for the integer upgrade to delete, not deprecate fileds. See discussion here - http://support.iatistandard.org/entries/78002476-Delete-previously-deprecated-items

Please sign in to leave a comment.