GONG

Analiza desde Semilla si el numero identificador de las facturas que se pone en delegación se podría poner también por proyecto.

La necesidad es poner una numeracion que permita localizar de forma unica una factura, siendo un numero correltativo por proyecto.

Hablamos Alberto y yo sobre el análisis de la numeración de las facturas desde proyecto.

Existen algunas dudas/certezas sobre como numerar:

1) Numerar por proyecto e implementador (cada implementador del proyecto tiene su propia secuencia), o se numera únicamente por proyecto.

2) La facturas que se numeran desde delegación no tendrían numero de proyecto.

3) Las facturas que se cofinancien mantendrán el numero de proyecto de su proyecto original.

Se piensa en analizar la situación de alguna otra ONG afin como VSF.

La implementación que se ha hecho tiene varios problemas:

1) Tal cual está hecho el migrate, se obliga a revisar para cada gasto todos los gastos ya registrados. Esto con 100 gastos no tiene problemas, cuando hay casi 150.000 gastos, las consultas pueden ser ridiculamente lentas. No sería mejor seleccionar todos los gatos de cada proyecto de forma ordenada e ir poniendoles su numero de factura?.

2) La forma en la que se ha implementado deja sin codigo de factura de proyecto todos aquellos gastos que se han introducido desde las delegaciones.

3) Como el numero de factura es un atributo propio del gasto y no vinculado al proyecto, se duplican números de factura en un proyecto.

Contesto sobre los comentarios

Santiago Ramos escribió:

La implementación que se ha hecho tiene varios problemas:

1) Tal cual está hecho el migrate, se obliga a revisar para cada gasto todos los gastos ya registrados. Esto con 100 gastos no tiene problemas, cuando hay casi 150.000 gastos, las consultas pueden ser ridiculamente lentas. No sería mejor seleccionar todos los gatos de cada proyecto de forma ordenada e ir poniendoles su numero de factura?.

Correcto. Hay que rehacer el migrate

2) La forma en la que se ha implementado deja sin codigo de factura de proyecto todos aquellos gastos que se han introducido desde las delegaciones.

Asi es. Es parte del diseño tal cual se ha dialogado con MB.

3) Como el numero de factura es un atributo propio del gasto y no vinculado al proyecto, se duplican números de factura en un proyecto.

Al igual que con las delegaciones los gastos vinculados a otro proyecto, que estan confinanciando, no aparecerían en esta numeración del proyecto.

ADVERTENCIA/CONCLUSIONES:

Despues de la charla, creo que se necesita contrastar con alguna otra ONG la solucion adecuada. Quiza es interesante el dialogo con APS dado que ellos tambien trabajaban con una numeración desde. Quiza se congela el desarrollo del ticket hasta esta comprobación.

(Tras analizar la problematica con Alberto y Santi)

Re-enfocamos el tema desde las siguientes condiciones:

1) Necesitamos una numeración que relacione el archivo real con el gasto en GONG.

2) Este proceso de numeración no es el mismo que el proceso final para el financiador (menú actual de proyecto de "Numeración de facturas"). necesitamos una numeración para el proceso de trabajo previo al cierre de proyecto (o de etapa de proyecto): Archivado en terreno, envio a sede.

• Socia local
• Delegación
• Sede.

4) Esta numeración debería ser única para el gasto y no duplicar numeraciones, como en el caso actual que ya tenemos una numeración por agente.

5) Esta numeración debería contemplar importaciones externas. Se impone la numeración que se le haya dado externamente.

La propuesta actual sería:

Crear una numeración para la gestión fisica de gastos (diferenciado de la numeración final para el financiador) que nos permita establecer una relacion entre el gasto en GONG y la factura fisica. Las caracteristicas serán:

1) Se trata de una numeración que si se vuelca desde fuera de GONG se impondrá la numeración (o el código) que venga de la importanción.

2) Se diferenciará los gastos que se hayan volcado/gestionado desde Proyecto o Delegacion y cada gasto será identificado univocamente en el sistema con la forma:

Fuente / Origen / Etapa / Numero

Con las siguientes caracteristicas:

2.1) Gastos gestionados desde delegación.

Se les pondra una numeración para etapa de la delagación como existe actualmente. Para localizar un gasto fisicamente un ejemplo sería:

Fuente: Delegación
Origen: MB_Colombia
Etapa: 2015
Numero: 1

2.2) Gastos gestionados desde proyecto.

Se le pondra una numeración dentro de cada proyecto en función del Proyecto / implementador y la etapa, es decir:

Fuente: Proyecto
Origen: CodigoProyecto / SociaLocalX
Etapa: Etapa Unica
Numero: 1

3) Esta numeración que ha creado automaticamente el sistema podrá ser alterada manualmente por el usuario, siempre y cuando dicha numeración no se repita en las condiciones propuestas.

NOTA: Para el proceso final de numeración para el financiador se propone establecer nuevas funcionalidades en el sistemas que permita la relación entre la numeración final para el financiador, y la numeración de gestión durante el proyecto, pudiendo mantenerse las 2 numeraciones o producir alteraciones (automaticas o facilitadas para el usuario) de la numeración de archivado por la numeración del financiador

Revisar el rendimiento de la solución aplicada. Existe un problema serio de degradación con la implementación propuesta.

Actualmente, con cargas masivas (importaciones) de gastos de un proyecto estoy viendo lo siguiente:

  Etapa Load (0.5ms)  SELECT `etapa`.* FROM `etapa` WHERE `etapa`.`agente_id` = 12 AND (fecha_inicio <= '2014-03-06' AND fecha_fin >= '2014-03-06') ORDER BY fecha_inicio LIMIT 1
  Proyecto Load (0.1ms)  SELECT `proyecto`.* FROM `proyecto` WHERE `proyecto`.`id` = 1076 LIMIT 1
  Gasto Load (426.0ms)  SELECT `gasto`.* FROM `gasto` WHERE (proyecto_origen_id = 1076 AND agente_id = 12 AND orden_factura_proyecto IS NOT NULL) ORDER BY `gasto`.`id` DESC LIMIT 1
  Gasto Load (56.3ms)  SELECT `gasto`.* FROM `gasto` WHERE (proyecto_origen_id = 1076 AND agente_id = 12 AND orden_factura_proyecto = 24) LIMIT 1
  Gasto Load (50.2ms)  SELECT `gasto`.* FROM `gasto` WHERE (proyecto_origen_id = 1076 AND agente_id = 12 AND orden_factura_proyecto = 25) LIMIT 1

...

  Gasto Load (50.0ms)  SELECT `gasto`.* FROM `gasto` WHERE (proyecto_origen_id = 1076 AND agente_id = 12 AND orden_factura_proyecto = 113) LIMIT 1
  Gasto Load (52.0ms)  SELECT `gasto`.* FROM `gasto` WHERE (proyecto_origen_id = 1076 AND agente_id = 12 AND orden_factura_proyecto = 114) LIMIT 1
  Gasto Load (388.4ms)  SELECT `gasto`.* FROM `gasto` WHERE (proyecto_origen_id = 1076 AND agente_id = 12 AND orden_factura_proyecto = 115) LIMIT 1
  SQL (0.3ms)  UPDATE `gasto` SET `orden_factura_proyecto` = 115 WHERE `gasto`.`id` = 197773

Es decir... más o menos tarda unos 50ms por cada gasto ya existente en el proyecto de ese implementador, luego si tuvieramos ya 1000 gastos registrados tardaría 5 segundos sólo en obtener el número consecutivo de un único gasto nuevo.

En lugar de un bucle esotérico que recorre todos los resultados... porqué no se hace esto mejor?:

Gasto.where(proyecto_origen_id: 1076, agente_id: 12).maximum(:orden_factura_proyecto)

Tarda poco más del doble de una consulta de las anteriores, pero creo que puede compensar:

   (117.2ms)  SELECT MAX(`gasto`.`orden_factura_proyecto`) AS max_id FROM `gasto` WHERE `gasto`.`proyecto_origen_id` = 1076 AND `gasto`.`agente_id` = 12
 => 282 

(siento el retraso en contestar no había leido el problema)

No soy capaz de entender por que se produce la búsqueda (a traves de todos los gastos) cada vez que se vuelca un nuevo gasto.

Me explico.

Buscamos siempre el ultimo gasto con orden de factura:

 Gasto.last(:conditions => ["proyecto_origen_id = ? AND agente_id = ? AND orden_factura_proyecto IS NOT NULL", proyecto_origen_id, agente_id]) 

En general el numero de factura que nos da, debería ser correcto, por que el numero es secuencial. Se hace una última comprobación dentro del loop para ver que ese numero no hubiese sido pillado previamente:

        loop do
           if Gasto.first(:conditions => ["proyecto_origen_id = ? AND agente_id = ? AND orden_factura_proyecto = ?", proyecto_origen_id, agente_id, numero])
             numero = (numero + 1)
             next
           else
             break
           end
        end

NOTA: Esto verifica, especialmente, que ese numero no hubiese sido asignado a través de alguna importación previa con el numero ya establecido y aunque no sea el ultimo gasto que hemos volcado el numero ya está pillado.

En el caso de que hubiese algún gasto con esa numeración (debido como decía a un volcado previo) toca recorrer unos cuantos gastos (o muchísimos gasto) hasta encontrar el siguiente numero libre.

Pero esto sucederá una sola vez. Por que el siguiente gasto que estés volcando ya no necesitaría recorrerlos todos por que el anterior gasto al que le has puesto una numeración ya ha pasado todos los gastos que estaban ocupados con una numeración que no podíamos repetir.

Con tu propuesta de buscar siempre el numero mas grande solo se hace un búsqueda, pero esa búsqueda tarda el doble que la otra según lo que me dices tu (en mi instancia de desarrollo no tengo datos como para que mis tiempos sean fiables). Osea que en realidad no veo un cambio significativo de tiempos.

Comentad como veis esto que digo, o que puede estar sucediendo, y en cualquier caso lo cambio a la propuesta que hacéis.

Tampoco se bien el porqué, pero está sucediendo con todas las importaciones que estoy haciendo.

La mejora en rendimiento no es significativa cuando se importa un sólo gasto, pero con dos gastos que se carguen ya empieza a notarse y si hablamos de cientos o miles de líneas de gasto en una importación se tiene que notar significativamente.

En cualquier caso, podemos ver cómo se comporta en algún sistema de pruebas. desarrollo.gong.org.es está actualizado con este cambio?.