Enhancement - Economía - Mostrar información de previsión de pagos pendientes y de pagos realizados

[juanSTIC]

• Closes Nueva funcionalidad - Economía - Mostrar información de previsión de pagos pendientes y de pagos realizados #6

Campos nuevos en Compromisos de Pago:

• expected_payments_detail: Almacena un string similar a 0|7.14|0|7.14|0|7.14|0|7.14|0|7.14|0|7.14 que contiene, separado por |, los importes de los pagos que deberán generarse para los próximos 12 meses, con la configuración actual del compromiso de pago. El sentido de almacenar este valor de este modo es para facilitar la explotación de los datos en kreporter (y potencialmente en cualquier otro contexto como en SinergiaDA) .
  Este valor se recalcula:

  1. En el momento de la instalación de este PR, mediante la ejecución del script SticUpdates/Migrations/20230802_feature_payments_prevision.sql
  2. Cuando se modifica cualquiera de los parámetros del CdP que resultan determinantes: first_payment_date, amount, end_date, periodicity, mediante LH
  3. Cada vez que se ejecuta la función recalculateAllFuturePaymentsViaSQL() la cual es llamada al final de la tarea mensual de generación de pagos recurrentes.
  4. Discreccionalmente al invocar a la acción action_recalculateAllFuturePaymentsViaSQL()

• pending_annualized_fee: Que almacenará la suma de los importes de los pagos que se deberán de generar a partir del próximo mes hasta fin del presente año (o hasta la fecha de baja, si es anterior a fin de año). También se incluyen los pagos puntuales que eventualmente pudieran tener fecha del próximo mes o posterior. Este valor se extrae del la cadena generada pare le campo expected_payments_details y se genera simultaneamente a esta, por lo que el recálculo se efectua en el mismo momento.
  En el momento de la instalación del PR se calcula este valor para todos los CdP activos que no tengan periodicidad puntual.

• paid_annualized_fee: Almacenará la suma de los importes de los pagos relacionados con estado pagado y con fecha de pago del año actual (incluso futuros, si hubiera). Este valor se recalcula:

  1. En el momento de la instalación de este PR, mediante la ejecución del script SticUpdates/Migrations/20230802_feature_payments_prevision.sql
  2. Si se modifica alguno de los siguientes campos de un pago relacionado: status, amount, payment_date, o si se borra un pago relacionado, o si se vincula o se desvincula un pago relacionado, vía ejecución de código en el método save() del módulo stic_Payments.
  3. Al cambiar el estado de una remesa de domiciliaciones a "Enviada" se recalcula el valor para todos los CdP involucrados en la remesa, vía SQL.
  4. Discreccionalmente al invocar a la acción action_recalculateCurrentYearTotalPaidViaSQL()

En el momento de la instalación del PR se recalcula este campo para todos los CdP que no tengan fecha de finalización o que esta sea del año actual.

Columnas en kreporter:

Se añaden de manera dinámica, 12 columnas en kreporter llamadas expected_payments_month_1, expected_payments_month_2, ... cada una de las cuales muestra el importe de pagos esperados en el mes indicado en el número a partir del mes próximo. Esta información se obtiene del campo expected_payments_detail.

Se ha añadido un informe en kreporter para ilustrar la funcionalidad Ejemplos - Economía - 07 - Previsión de pagos

Pruebas a realizar

• Realizar diversos cambios en diversos CdP de manera que el contenido de los campos pending_annualized_fee y expected_payments_detail se modifican mostrando la información precisa en base a la configuración del CdP.

• Ejecutar la tarea de generación de pagos recurrentes y verificar que, tras aplicarla:

  1. El contenido de los campos pending_annualized_fee y expected_payments_detail recoge correctamente la situación actual en todos los CdP activos.
  2. Si la ejecución corresponde al mes de enero, el contenido del campo paid_annualized_fee se borra en todos los compromisos de pago.

• Verificar que el campo paid_annualized_fee cambia al valor correcto tras cada una de las siguientes acciones:

  • Modificar en diversos pagos relacionados alguno de los campos status, amount, payment_date.
  • Vincular y desvincular algunos pagos relacionados
  • Borra algún pago relacionado.

• Crear un informe basado en CdP y hacer uso de las columnas creadas para mostrar la proyección de pagos mes a mes y verificar que todo funciona correctamente.

• Verificar que se ha creado y el funcionamiento del informe Ejemplos - Economía - 07 - Previsión de pagos

• Crear una remesa de domiciliaciones y añadir algunos pagos. Verificar que tras cambiar el estado de la remesa a Enviada, los pagos cambian correctamente a Pagado y simultaneamente esto fuerza el recalculo del campo paid_annualized_fee (todo mediante SQL)

• Verificar el funcionamiento del script SticUpdates/Migrations/20230802_feature_payments_prevision.sql. que deber recalcular mediante SQL el contenido de los 3 campos creados, para ello:

  1. Eliminar el contenido de estos tres campos mediante la sentencia update stic_payment_commitments set paid_annualized_fee = null, expected_payments_detail=null, pending_annualized_fee=null where 1
  2. Ejecutar el script y verificar que los tres campos se pueblas con los valores correctos en todos los CdP activos.

• Verificar el funcionamiento de las acciones definidas en el controller de CdP.

  1. Volver a eliminar el contenido de los 3 campos con la sentencia SQL anterior
  2. Ejecutar la acción que recalcula la previsión de pagos en la consola del navegador location.href='index.php?module=stic_Payment_Commitments&action=recalculateAllFuturePaymentsViaSQL'
  3. Ejecutar la acción que recalcula el importe ya pagado del año en curso: location.href='index.php?module=stic_Payment_Commitments&action=recalculateCurrentYearTotalPaidViaSQL'

[github-actions]

Actions executed at: 2024-03-21 08:00:33.

[jalbaiges]

Cadenas revisadas.

[enricsinergia]

Pruebas realizadas:
Crear CdP desde subpanel
Crear CdP desde vista edición

• Pago actual
• Pago atrasado
• Pago futuro
  Crear pago (atrasado) desde subpanel de CdP
  Añadir un pago (pagado y no pagado) a un CdP
  Cambiar estado a pago a pagado e impagado
  Crear nuevo pago pagado (se echa de menos el refresco automático)
  Cambiada periodicidad a CdP
  Creada remesa i enviada a pago (incluso remea grande > 20.000 registros)
  Informe previsión

Aparte de los comentarios, punto detectado: introdución de pagos futuros:
El cálculo cuando hay pagos futuros introducidos o es correcto. Se podría incorporar a recalculateAllFuturePaymentsViaSQL la suma de los pagos futuros y restarla de la calculada. Otra alternativa sería calcular la proyección primero y luego cuando se calcula el importe pagado, modificar esa SQL para que calcule lo pagado con fecha anterior y con fecha posterior, y actualice los 2 importes.
Hay algunas entidades que al captar una cuota, ésta se introduce con fecha del 1 del mes siguiente, por lo que estos cálculos podríanintroducir un desvío importante.
También está el caso de introducir cuotas con fecha futura para establecer un precio por debajo del que marca el CdP (puede ser una oferta puntual de 3 meses, una negociación para no perder un socio...)
También habría que modificar, si se quieren tener presentes esos pagos futuros, el LH cuando se cambia el estado de pago para recalcular esta proyección.

En las pruebas, a pesar de tener un cierto volumen, no he notado lentitud. De todas formas, no sería descabellado pensar en incluir un índice en pagos por fecha.

[juanSTIC]

Pruebas realizadas: Crear CdP desde subpanel Crear CdP desde vista edición

• Pago actual
• Pago atrasado
• Pago futuro
  Crear pago (atrasado) desde subpanel de CdP
  Añadir un pago (pagado y no pagado) a un CdP
  Cambiar estado a pago a pagado e impagado
  Crear nuevo pago pagado (se echa de menos el refresco automático)
  Cambiada periodicidad a CdP
  Creada remesa i enviada a pago (incluso remea grande > 20.000 registros)
  Informe previsión

Aparte de los comentarios, punto detectado: introdución de pagos futuros: El cálculo cuando hay pagos futuros introducidos o es correcto. Se podría incorporar a recalculateAllFuturePaymentsViaSQL la suma de los pagos futuros y restarla de la calculada. Otra alternativa sería calcular la proyección primero y luego cuando se calcula el importe pagado, modificar esa SQL para que calcule lo pagado con fecha anterior y con fecha posterior, y actualice los 2 importes. Hay algunas entidades que al captar una cuota, ésta se introduce con fecha del 1 del mes siguiente, por lo que estos cálculos podríanintroducir un desvío importante. También está el caso de introducir cuotas con fecha futura para establecer un precio por debajo del que marca el CdP (puede ser una oferta puntual de 3 meses, una negociación para no perder un socio...) También habría que modificar, si se quieren tener presentes esos pagos futuros, el LH cuando se cambia el estado de pago para recalcular esta proyección.

En las pruebas, a pesar de tener un cierto volumen, no he notado lentitud. De todas formas, no sería descabellado pensar en incluir un índice en pagos por fecha.

Se descarta esta propuesta debido a la dificultad de contemplar las diferentes casuisticas que pueden provocar que haya pagos futuros registrados en el CRM, incluyendo los pagos en que se indica fecha de primer pago futura, o situaciones en que se hacen ajustes a los usuarios creando pagos futuros con importes diferentes al del CdP, pero que impediran que se genere el pago concurrente del mes ...

[enricsinergia]

(A)provado

[AlbertoSTIC]

Aprobado

[enricsinergia]

(A)provado