Detailed transaction, budget, external budget data linkages #483
Comments
|
Expanding a little on the modelling of budget classifications I have been taking a look at Mexico's Open Fiscal Data Package pipeline along with a randomly selected budget line from the Transparencia Presupuestaria OFDP site to see whether the budget classifications used there could be represented using the model proposed by Tim. I'm proposing a slightly different modelling which:
Proposed modelling"classifications": [
{
"id": "GPO_FUNCIONAL",
"type": "functional",
"title": "Grupo Funcional",
"code": {
"value": "1",
"description": "Gobierno"
}
},
{
"id": "FUNCION",
"type": "functional",
"title": "Función",
"code": {
"value": "2",
"description": "Justicia"
}
},
{
"id": "SUBFUNCION",
"type": "functional",
"title": "Subfunción",
"code": {
"value": "4",
"description": "derechos Humanos"
}
},
{
"id": "AI",
"type": "functional",
"title": "Actividad Institucional",
"code": {
"value": "2",
"description": "Servicios de apoyo administrativo"
}
},
{
"id": "CAPITULO",
"type": "economic",
"title": "Capítulo",
"code": {
"value": "3000",
"description": "Servicios generales"
}
},
{
"id": "CONCEPTO",
"type": "economic",
"title": "Concepto",
"code": {
"value": "3300",
"description": "Servicios profesionales, científicos, técnicos y otros servicios"
}
},
{
"id": "PARTIDA_GENERICA",
"type": "economic",
"title": "Partida Genérica",
"code": {
"value": "339",
"description": "Servicios profesionales, científicos y técnicos integrales"
}
},
{
"id": "PARTIDA_ESPECIFICA",
"type": "economic",
"title": "Partida Específica",
"code": {
"value": "33901",
"description": "Subcontratación de servicios con terceros"
}
},
{
"id": "RAMO",
"type": "administrative",
"title": "Ramo",
"code": {
"value": "47",
"description": "Entidades no Sectorizadas"
}
},
{
"id": "UR",
"type": "administrative",
"title": "Unidad Responsable",
"code": {
"value": "AYJ",
"description": "Comisión Ejecutiva de Atención a Víctimas"
}
},
]There are also a number of other categorizations of the budget lines in the Mexico data, which could be expressed as part of a classifications array as follows "classifications": [
{
"id": "ENTIDAD_FEDERATIVA",
"type": "geographical",
"title": "Entidad Federativa",
"code": {
"value": "9",
"description": "Ciudad de México"
}
},
{
"id": "FF",
"type": "Fuente de Financiamiento",
"title": "financialSource",
"code": {
"value": "1",
"description": "Recursos fiscales"
}
},
{
"id": "MODALIDAD",
"type": "activity",
"title": "Modalidad",
"code": {
"value": "M",
"description": "Apoyo al proceso presupuestario y para mejorar la eficiencia institucional"
}
},
{
"id": "PP",
"type": "activity",
"title": "Programa Presupuestario",
"code": {
"value": "1",
"description": "Actividades de apoyo administrativo"
}
},
{
"id": "TIPOGASTO",
"type": "expenditureType",
"title": "Tipo de Gasto",
"code": {
"value": "1",
"description": "Gasto corriente"
}
},
]Issues and questionsFurther to Tim's questions, I'd like to understand whether including these additional types of classification is: a. necessary to identify budget lines |
|
Is there a strong reason to nest Why not: {
"id": "TIPOGASTO",
"code":"1",
"type": "expenditureType",
"title": "Tipo de Gasto",
"description": "Gasto corriente"
}And we might even find that |
There are two possible sets of ids/titles/descriptions in use here:
So the the Suggestions on better naming conventions welcome, does talking about a value drawn from a classification make more sense? Example - budget line A:"classifications": [
{
"id": "institutionalActivity",
"type": "functional",
"title": "Institutional Activity",
"value": {
"code": "2",
"description": "Administrative support services"
}
}
]Example - budget line B:"classifications": [
{
"id": "institutionalActivity",
"type": "functional",
"title": "Institutional Activity",
"value": {
"code": "3",
"description": "IT services"
}
}
] |
|
Thanks for the clarification. I've been looking at the Fiscal Data Package (http://specs.frictionlessdata.io/fiscal-data-package/#examples) and Open Spending (http://docs.openspending.org/en/latest/) for terminology precedents to use here. I didn't find anything solid, but the one term that did come up was 'dimension'. That could be useful in place of 'title', so we say Reviewing the merging guidance I think we would want to treat the value of a classifications array as wholeListMerge so could omit the id values from within the objects. |
|
Following up on several conversations with Duncan from the helpdesk we wanted to add some documentation to the way we at Mexico’s Ministry of Finance are modelling the link between the OCDS and the Open Fiscal Data Standard (OFDS):
Each classification has concepts that relate hierarchically. For example, the Economic classification has 4 concepts from which “Partida Específica” is the most disaggregated one. But in order to have a “Partida Específica” you first need to have a “Partida Genérica” a “Concepto” and a “Capítulo”. Economic Classification
MeasuresProposed structure for budgetBreakdownFind hereby an example of our proposed structure to integrate OFDP with OCDS, within the OCDS structure: It’s important to mention that Classification needs to be arrays since a single Budget can be expressed in several ones. Also, you can take a detailed look to our proposal in this Google Drive link: |
|
@transpresupuestaria Thank you for sharing this: it's really useful to see. I'm pasting in your budgetBreakdown.txt example below for others reading this thread, and will add some comments to check my understanding. "budgetBreakdown": [
{
"id": "09G001",
"description": "RegulaciÛn y supervisiÛn del programa de protecciÛn y medicina preventiva en transporte multimodal",
"budgetClassification": [
{
"classification": "administrative",
"levelId": 2,
"levelLabel": "Unidad Responsable",
"id": 313,
"description": "DirecciÛn General de ProtecciÛn y Medicina Preventiva en el Transporte",
"measures": [
{
"id": "Comprometido",
"value": [
{
"amount": 20509,
"currency": "MXN"
}
]
},
{
"id": "Devengado",
"value": [
{
"amount": 20509,
"currency": "MXN"
}
]
},
{
"id": "Ejercido",
"value": [
{
"amount": 20509,
"currency": "MXN"
}
]
},
{
"id": "Pagado",
"value": [
{
"amount": 20509,
"currency": "MXN"
}
]
},
]
},
{
"classification": "economic",
"levelId": 4,
"levelLabel": "Partida EspecÌfica",
"id": 35701,
"description": "Mantenimiento y conservaciÛn de maquinaria y equipo",
"measures": [
{
"id": "Comprometido",
"value": [
{
"amount": 20509,
"currency": "MXN"
}
]
},
{
"id": "Devengado",
"value": [
{
"amount": 20509,
"currency": "MXN"
}
]
},
{
"id": "Ejercido",
"value": [
{
"amount": 20509,
"currency": "MXN"
}
]
},
{
"id": "Pagado",
"value": [
{
"amount": 20509,
"currency": "MXN"
}
]
}
]
}
]
}
]ObservationsObservation 1: sectionsThe measures (translated as Comprometido = Committed; Devengado = Accrued; Ejercido = Exercised; Pagado = Paid) represent the different states that a budgetary commitment goes through. In OCDS core we have support for two of these concepts:
For conformance, and so that tools expected OCDS core data can interpret the data, the paid information should go into Conceptually, it doesn't seem right to have amounts paid in the OCDS Observation 2: structureThese are in the form of questions:
E.g. would there ever be a case where the amounts in the second entry in the If the answer is no, then we seem to be duplicating a lot of information that could be expressed at the
If not, then it may be sensible to create specific properties for these concepts, rather than to abstract them out. E.g. {
"valueCommitted":{
"amount":20509,
"currency":"MXN"
},
"valueAccrued":{
"amount":20509,
"currency":"MXN"
},
"valueExcercised":{
"amount":20509,
"currency":"MXN"
}
}This will be easier for users engaging with the data in spreadsheets to process (as each one would become a column, rather than normalised sub-tables to analyse). This would also allow each concept to be clearly defined. Observation 3: CompatibilityEven if you do have a deeper breakdown of the nature of the budget measures, the committed amount should still be included at the Term suggestionsSome minor suggestions for consistency with how OCDS terminology usually works:
Related IssuesAre the amounts in your example the amounts reserved for the specific contracting process or for the whole budget line? We have an open issue #460 on the definition of budget.amount where it would be great to get your input. Our strong working assumption is that budget.amount in OCDS should be the amount specifically reserved for the particular contracting process described, with higher-level budget information in separate datasets. |
|
Hi all: Budget line classification.Considering the comment about hierarchical classifications, what I’ve see in the budget dataset from Paraguay, and also from Argentina and Honduras, normally there are several hierarchical classifications in the budget. For instance, in the data dictionary from Paraguay we can see that there are these hierarchies:
As we can see, some of them are obvious given the encoding, but some other are not. Perhaps we can think about adding a “parent” attribute used in Fiscal Data Package? This would mean something like this: "classifications": [
{
"id": "GrupoObjetoGastos",
"type": "XXX",
"title": "Grupo objeto de gastos",
"description": "Representa el identificador y la descripción del Grupo de Objeto de Gasto...",
"value": {
"code": "100",
"description": "SERVICIOS PERSONALES"
}
},
{
"id": "SubGrupoObjetoGastos",
"type": "XXX",
"title": "Sub Grupo objeto de gastos",
"parent": "GrupoObjetoGastos",
"description": "Representa el identificador y la descripción del Subgrupo de Objeto de Gasto...",
"value": {
"code": "140",
"description": "PERSONAL CONTRATADO"
}
},
{
"id": "ObjetoGastos",
"type": "XXX",
"title": "Objeto de gastos",
"parent": "SubGrupoObjetoGastos",
"description": "Corresponde a la descripción del objeto de gasto…..",
"value": {
"code": "145",
"description": "HONORARIOS PROFESIONALES"
}
}
]Notes:
Considering the transaction blocksWhen referencing the budget line by budgetBreakdownID, besides (or instead) of defining which “proportion” of the payment was done using the referenced budget line, it would be good to defined the actual amount that was used for performing the transaction, for each budget line. This could be particularly important when paying large amounts of money, and therefore, specifying the proportions in terms of real numbers might not always give the exact amount of the budget line used (think about paying 9000 USD, and using 2 budget lines with 3000 USD and 6000 USD for each line, the proportions have infinite decimals. Note that if we use 0.33 for the proportion of first budget line this would mean 2970 USD instead of 3000 USD). The json file could look something like this: "contracts": [
{
"id": "ocds-exa123-72856037693-contract",
"awardID": "ocds-exa123-72856037693-award",
"implementation": {
"transactions": {
"id": "ocds-exa123-72856037693-transaction-01",
"value": {
"amount": "9000",
"currency": "GBP"
},
"budgetSource": [
{
"budgetBreakdownID": "0023/loc/health/cap",
"proportion": 0.33333333,
"amount": “3000”
},
{
"budgetBreakdownID": "10.24/nat/cycl/prj",
"proportion": 0.66666666,
"amount": “6000”
}
]
}
}
}
] |
|
Hey @timgdavies , thanks for the feedback. Regarding your questions and observations: 1: sections.
2: Structure.
Even though different classification express the same value, their specific concepts can have different values as shown in the following example: This example shows the behavior of the different measures for the same contract which is being implemented by three organizations (admin. Classification), yet all of them are using the same line item (economic classification). As you can see, there is no duplication of information.
Comprometido, Devengado, Ejercido and Pagado are some of the accruing moments specified by our law. However, other countries can have different concepts or names for their accruing moments. That is why the Open Fiscal Data Standard only asks for “Measures” to express the monetary value of their classification, and each country can use their own. 3: Compatibility.Does the above comments about the committed amount clarifies this point? If not, do you have an example of how would what you are proposing would look like? Term suggestionsWe’re Ok with your terminology suggestions. Related issues:We’ll be participating in issue #460 but we plant to leave planning/budget/amount empty since:
Comments on Juan Pane Intervention.It seems that the example given by @juanpane is similar to our budget classifications:
However, our idea would be not to repeat all the concepts in each classification, but only include the most disaggregated one and have the others stay in the Open Fiscal Data Standard information in order not to duplicate information between standards. That is why, instead of using a parent code we specify a level so that the user can know the level of disaggregation used for each classification. |
|
considering the last comment from @transpresupuestaria
This would be great, as long as the user of the data has a way to automatically reaching that information from the data being consumed, for instance, by the URI of the budget line, where the parent concepts are shown when the URI is resolved. |
Different phases of budget execution and contracts:Different countries have different (but similar) phases for managing the impact of a procurement process in the National Budget. I’ll try to do my best to try to explain (a simplified version) of 2 countries, Paraguay and Honduras. ParaguayIn Paraguay these are the phases:
Note that the first two refer to the budget line or budget lines for the procurement process as a whole, while the latter two refer to the payments. HondurasIn Honduras, there are 3 steps related to the budget for managing a procurement process, all of which are also managed in the SIAFI of the Ministry of Finance of Honduras.
SummaryThere seems to be a similar terminology/concepts in managing the budget lines and the payment information that is related to the budget lines. I’ll try to summarize the concepts and their relations for each country
Note that in the Mexican case I’m not sure, as I haven’t found an explanation of what each phase (Comprometido, Devengado, Ejercido, Pagado) means or imply. @transpresupuestaria, could you be so kind to explain these concepts? Use caseSome ideas come to mind for using this information:
|
|
@transpresupuestaria @juanpane thanks both for your contributions on this issue This is has been really useful to surface a couple of different understandings of the use of My understanding from the discussion so far is as follows:
Since an OCDS release is designed to represent information about an individual contracting process, and further to the discussion in #460, niether |
jpmckinney
added
the
Focus - Extensions
|
@duncandewhurst thanks for your comments.
• Only the accruing momento “Aprobado” refers to the the whole Budget program as it appears in the Presupuesto de Egresos de la Federación, which is the national government’s main planning document. So, the story we’re trying to tell go as follows:
Up until now, we’ve been under the impression that “budget” is a block used in the planning stage (“planning/budget”). Even though the accruing moments specified by @juanpane all refer to an individual contracting process, it’s not clear why would they belong to a planning stage of the Budget. The “Expected Budget” seems more as a pre-requisite for committing Budget than an amount that has been reserved for a contract since an early planning stage. @juanpane can you please point us out to a specific data set to locate where we can locate the “planning” info per contract? If you could also help us with a bit of instructions on navigating it once you point it out it would be awesome. Answering to @juanpane, our accruing moments would fit as follows (for more information, you can find our data dictionary here):
Therefore we consider that the most appropriate way to include the “Aprobado” and “Modificado” accruing moments would be in the planning stage, this, in terms of disclosing full, linkable, information about budget and contracts in its most disaggregated form (budget line), and covering all the processes needed for procuring payments. |
|
I'm under the impression that we might be mixing things here. OCDS deals only with a specific contracting process, and as @duncandewhurst said, when we talk about planning/budget, it refers only to the budget that we plan for a particular contracting process, The national budget planning, which on its own its a complete different thing (although related) with its own set of rules, moments, changes, etc., is out of the scope of OCDS data, and therefore details of moments and changes for it should not be included if possible, say, if for example there is another dataset that can be referenced to, that contains all these details. In Paraguay, all the contracting information can be found in https://contrataciones.gov.py/ We are right now working on publishing the detailed budget information related to the contracting process (Certificado de disponibilidad presupuestaria, pagos, etc), however, the national budget information, including the initial approved amount, all the modifications, and the amount that has been spent so far can be found here: https://datos.hacienda.gov.py/data/pgn-gasto As I said, the national budget process itself is a complex issue, and for instance, Paraguay publishes the information on how the budget was negotiated before it was actually approved by law. You can find this information in this dataset https://datos.hacienda.gov.py/data/pgn-etapas Note however that the national budget information is out the scope of the contracting process (as it is published by Ministerio de Hacienda) in a different portal. However, the fact that there is a URI for each budget line allows the planning/budget element of OCDS to reference to it (in Paraguay this is work in progress, as the budget lines URIs are fairly new) I hope this helps |
Maybe to be clear we need to re-state the purpose of our display of the data. What we’re doing is connecting the budget information (as presented by the Open Fiscal Data Package) with the contracting process information. The budget information has two main stages to be included at:
This is how we will consolidate our efforts to connect the Open Fiscal Data Standard and the Open Contracting Data Standard. @juanpane we checked out the Paraguay’s information you kindly sent us and we found that the planning information has an estimate global amount:
In any case, maybe it is the terminology which is confusing. We are understanding planning as the moment in which the “whom”, “what” and “where” is the money spent is defined (aprobado), BEFORE the procurement process starts (comprometido). In that same understanding, the Paraguayan example (please correct us if wrong) is including in planning an administrative pre-requisite that allows to know that there is money for that specific allocation, therefore, that there is an specific approved and/or modified budget for that contract, which in this case will be the same as we are conceptualizing it in the Mexican case. Therefore, we believe all cases where the understanding is the same could be modelled with the model we are proposing and will accomplish to:
What do you think @duncandewhurst @timgdavies @juanpane ? |
jpmckinney
changed the title
|
It might have been a while since this issue was updated: but we've been working on this at length - with discussions at OC Global 2017, a discussion paper prepared earlier this year, conversations with the Open Knowledge Fiscal Data Package team, and discussions at OGP Tbilisi. The result is a draft ocds budgets and spend extension which comes with a number of worked examples to illustrate how it can operate in practice. The issue tracker for the extension is turned on, and we would welcome feedback on it there. |
jpmckinney
changed the title
jpmckinney
added
Extensions - Drafted
|
The extension has been added to the extension registry. Issues about the extension can be opened at https://github.com/open-contracting/ocds-extensions/issues |
Primary use case
A publisher wants to indicate the budget line that a transaction was paid from.
Considerations
A budget line may not have a clear unique identifier or URI. Where no unique identifier is available, budget lines may be identified by a range of classifications, including:
If these are repeated in each transaction, we risk a lot of 'bloat' within a dataset.
A single transaction may be funded by more than one budget item.
Related issues
#432 looks at providing a
fundingSourceissue at the line-item level#460 addresses the need to make sure the definition of
budget/amountcovers 'amount assigned to this project', not overall budget value#400 on separating out project value from budget value
#345 on removing links to the Fiscal Data Package at URI level
Modelling proposal
Using the budget breakdown extension a publisher can provide a list of identifiers for budget lines (
budgetBreakdown/0/id) and the amount allocated to this contracting process from that budget line.The budget breakdown extension can be further extended to provide classification information for each entry in the breakdown.
Transactions can then include a
budgetSourcearray providing internal cross-references back to the budgetBreakdown items.Example
The example below mocks up a project which is funded through two budget lines. Each budget line is identified in the budget breakdown section. There is a single transaction, paid for 50% out of one budget line, and 50% out of the other.
{ "releases": [ { "planning": { "budget": { "period": { "startDate": "2016-01-01T00:00:00Z", "endDate": "2016-12-31T00:00:00Z" }, "id": "ocds-exa123-72856037693", "description": "string", "amount": { "amount": 300000, "currency": "GBP" } }, "budgetBreakdown": [ { "id": "0023/loc/health/cap", "description": "Budget contribution from the local government", "amount": { "amount": 150000, "currency": "GBP" } }, { "id": "10.24/nat/cycl/prj", "description": "Budget contribution from the national government", "amount": { "amount": 150000, "currency": "GBP" } } ] }, "contracts": [ { "id": "ocds-exa123-72856037693-contract", "awardID": "ocds-exa123-72856037693-award", "implementation": { "transactions": { "id": "ocds-exa123-72856037693-transaction-01", "value": { "amount": "10000", "currency": "GBP" }, "budgetSource": [ { "budgetBreakdownID": "0023/loc/health/cap", "proportion": 0.5 }, { "budgetBreakdownID": "10.24/nat/cycl/prj", "proportion": 0.5 } ] } } } ] } ] }Then within the budget breakdown we could then include an array of classifications and optional
uri. I've based the example below on random data from the UK OSCAR in year data release as I'm no expert on budget categories. I've also included a classificationtypeproperty with a codelist based on the classification fields in the Fiscal Data Package.{ "budgetBreakdown": [ { "id": "0023/loc/health/cap", "description": "Budget contribution from the local government", "amount": { "amount": 150000, "currency": "GBP" }, "uri":"http://example.com/AME/DEPT_AME/DCMS/X048A105/A101/RESOURCE" "classifications": [ { "code": "Control Budget Code", "value": "AME", "type": "economic" }, { "code": "Control Budget Detail Code", "value": "DEPT AME", "type": "administrative" }, { "code": "Segment Department Long Name", "value": "Department for Culture, Media and Sport", "type": "administrative" }, { "code": "Sub Segment Code", "value": "X048A105", "type": "administrative" }, { "code": "Economic Category Code", "value": "A101", "type": "functional" }, { "code": "Economic Budget Code", "value": "RESOURCE", "type": "functional" } ] } ] }Additional use cases and approaches
Scenario: A user wants to reconcile spending transactions against original budget lines.
Approach:
classificationsorurito match against budget lines in an external budget databaseFrom this, it is possible to see:
Issues and questions
The text was updated successfully, but these errors were encountered: