Ocultar las partidas generales de GONG y crear agrupaciones.¶

• Ocultar las partidas generales de GONG y crear agrupaciones.
  • Detalle terminologico.
  • ¿ Que problema se están dando para la definición de las partidas generales de GONG ?
    • Organizaciones que mezclan partidas con actividades.
    • Definen las partidas como partidas de contabilidad.
    • Han creado deferentes suites.
    • La gente se hace un lio: idea enrevesada
  • ¿ Para que sirven las partidas de GONG ?
  • Solución: Agrupación de partidas y "desabilitar" partidas de GONG por proyecto.
    • Ventajas de la solución
    • Compartir gastos entre proyectos
    • Compartir gastos desde delegaciones a proyectos.
• Cambios en el software.
  • Modelo de datos.
  • Cambios en la vista y en la logica.
  • Migración de los datos actuales.

Detalle terminologico.¶

Llamaremos:

• A las partidas base, o generales de GONG las llamamos de tres formas:
  • Simplemente Partidas
  • Partidas de GONG.
  • Partidas generales de GONG.
• A las partidas especificas de proyecto, tambien llamadas a veces partidas del financiador o partidas de financiacion: Partidas de proyecto.

¿ Que problema se están dando para la definición de las partidas generales de GONG ?¶

Organizaciones que mezclan partidas con actividades.¶

Tanto Misereor (Iglesia de Alemania) como PPM (Gobierno Alemania), que financian a la CPT y a ANSA, ocurre esto.

Pongo 2 ejemplos de su contrato que es a su vez su formulario de prestación de cuentas (en anexo).

Definen las partidas como partidas de contabilidad.¶

Con los siguientes problemas:

• Son inmanejables y de un lenguaje poco amigable para la gestión de los proyectos
• Pese a ser muchas, no encajan en las necesidades y para el para el mapeo con las partidas del financiador

(Alvaro expone el ejemplo del CISP.. concretándolo en un ejemplo de esas partidas que vamos a tener que duplicar...)

Han creado deferentes suites.¶

Hay organizaciones que estan creando al menos dos grupos de partidas: Desarrollo, ayuda humanitaria.

(Jaime expone el caso de Mundubat)

La gente se hace un lio: idea enrevesada¶

Existen diferentes conceptos bajo la idea de las partidas para cada organización, para cada perfil, para cada país.

(Alvaro expone el caso)

¿ Para que sirven las partidas de GONG ?¶

Para unificar la gestión de la información económica, teniendo un lenguaje común y trasversal a toda la organización. Detallándolo:

• Nos permite gestionar los gastos/presupuestos siempre con las mismas partidas para los diferentes proyectos.
• Nos permite gestionar los gastos de forma común para poder asignar gastos de las delegaciones a los proyectos.
• Nos permite gestionar los gastos de forma común para el intercambio de proyectos entre proyectos (cofinanciación)
• Permiten elaborar un presupuesto común y "compartible" entre delegaciones, y un análisis de gastos también común.
• Permite tener una información trasversal con la que podremos tener un cuadro de mando común (en el futuro)

Solución: Agrupación de partidas y "desabilitar" partidas de GONG por proyecto.¶

La solución se basa en la abrir la posibilidad de:

• Crear agrupaciones de partidas.
• Anular la relación de partidas de proyecto con las partidas generales. El sistema te crea una suite de partidas generales de GONG para tu proyecto.

Por un lado permite tener diferentes grupos de partidas generales para diferentes enfoques de proyecto, dando flexibilidad para tener agrupaciones como por ejemplo:

• Partidas de desarrollo proyectos rurales.
• Partidas de sensibilización en el norte.
• Partidas de ayuda humanitaria.

Por otro encaja con la idea de anular las partidas generales en la gestión de un proyecto:

1. Por proyecto se anulan las partidas diciendo que tiene una agrupacion propia de partidas
2. La anulación de partidas hace que en la creación de las partidas del proyectos, no se puedan elegir partidas generales de GONG por que automáticamente se crea para cada proyecto:
   1. Un agrupación de partidas con el nombre del proyecto ( Agrupación de partidas: CO_MUJERES_2019 )
   2. Una partida para cada partida de proyecto.

El usuario tendrá la impresión de estar utilizando partidas especificas del proyecto, aunque estás partidas estén mapeadas (una a una) a partidas de GONG.

Finalmente las delegaciones se vincularán a una agrupación de partidas.

Ventajas de la solución¶

No altera el modelo de datos. Así, en el caso de no utilizar las partidas generales de GONG

• No es necesario cambiar la lógica de los formularios, ni del modelo.
• No es necesario cambiar las búsquedas en los resúmenes (esto es lo mas importante)

Es flexible. Permite 3 modelos:

• Tengo partidas de GONG fijas.
• Tengo partidas de GONG pero necesito flexibilidad según el tipo de proyectos.
• No tengo partidas de GONG. (el sistema crea una agrupación de partidas de GONG para cada proyectos.)

Encaja con el uso que está haciendo implicitamente algunas organizaciones ( Ejemplo: Mudubat que es una organización avanzada en el uso de la gestión económica)

Y finalmente es compatible con la posibilidad de analizar trasversalmente en el futuro todos tus gastos: ¿Como? Creando en el futuro un modelo de "meta-partidas-generales". De esta forma al menos las organizaciones que han utilizado las partidas generales de GONG (aunque sea creando varios grupos) podrán tener un cuadro general que les muestre información por partidas

Compartir gastos entre proyectos¶

Cuando se quiera compartir gastos entre proyectos (cofinanciación) será necesario que previamente en el proyecto se relacionen las partidas del otro proyecto con las partidas del proyecto que se quiere que cofinancien el proyecto.

NOTA: En realidad este deberia ser el comportamiento actual: No se pueden seleccionar gastos de otros proyectos si las partidas con gastos del otro proyecto no estan ya relacionadas con las partidas del proyecto.

Compartir gastos desde delegaciones a proyectos.¶

Cuando desde una delegación se asocie un gasto a un proyecto se puede dar el caso de que no se comparten partidas. En ese caso es necesario que el sistema avise de que se ha vinculado un gasto, que pertenece a una partida que no está mapeada dentro del proyecto.

NOTA: Actualmente, e independientemente de la existencia de agrupaciones de partidas, también es interesante este comportamiento.

Cambios en el software.¶

Detallamos aqui los cambios en el software para que tener una idea mas clara de la descripcion funcional que acabmos de hacer:

Modelo de datos.¶

• Creamos la entidad agrupacion_partidas.
• Modificamos la entidad partida: Añadimos cambpo agrupacion_partida_id
• Modificamos la entidad agente: Añadimos campo agrupacion_partida_id
• Modificamos la entidad Proyecto:
  • Añadimos campo agrupacion_partida_id
  • Añadimos campo agrupacion_propia: boolean.

Cambios en la vista y en la logica.¶

En administración > parametrización:

1. Crear vistas en parametrización para la gestión de agrupaciones de partidas.
2. Crear filtro en partidas para agrupación de partidas.
3. Cambiar formulario de partidas para vincular partidas a agrupación de partidas.
4. Cambiar Formulario de agente para vincular agente a agrupación de partidas.
5. Cambiar Formulario de proyecto para vincular proyecto a agrupación de partidas e incluir el booleano "agrupación de partidas propia"

En Agentes:

1. Modificar los formularios de agentes para que solo muestre las partidas de la agrupación seleccionada:
   1. Formulario de gasto.
   2. Formulario de presupuesto.
2. Modificar los resúmenes, para que en los resúmenes de partidas solo aparezcan partidas mapeadas a las partidas del proyecto.

En proyecto.

1. En la gestión de partidas del proyecto:
   1. Que aparezcan para mapear las partidas con un desplegable previo en el que se elige la agrupación (por defecto saldrá la agrupación configurada para el proyecto).
   2. Revisar avisos y bloqueos cuando se intenta desvincular partidas generales, o borrar partidas de proyecto que tienen datos, y el de que que faltan partidas por mapear solo si faltan partidas de la agrupación configurada.
   3. Cuando se ha configurado un proyecto con la opción "agrupación de partidas propias" se sincronicen las partidas del proyecto con las partidas generales de la agrupación:
      1. Cada vez que se da de alta una nueva partida del proyecto se da de alta en el sistema, en la agrupación especifica del proyecto. (se identifica por que tendrá el mismo codigo)
      2. Cada vez que se modifica una partida del proyecto se modifica la partida en el sistema en la agrupación especifica del proyecto.
      3. Cada vez que se elimina una partida del proyecto se elimina la partida en el sistema en la agrupación especifica del proyecto. Siempre y cuando sea eliminable.
      4. la partida creada en el sistema con el mismo código que la partida del proyecto no se puede modificar (ni desvincular)
2. En la cofinanciación no aparece ningún gasto de ninguna partida no mapeada.
3. Cuando desde agente se vincula un gasto a un proyecto de una partida no mapeada se añadirán avisos y mensajes de advertencia en los gastos.

Migración de los datos actuales.¶

Para migrar los datos actuales serfá necesario:

• Crear una agrupación inicial para todas las partidas que se llame: agrupacion por defecto.
• Vinculara a la "agrupación por defecto":
  • Todas las partidas.
  • Todos los proyectos.
  • Todos los agentes.