Saltar al contenido principal

Manual de integración Debi (TuCuota) a Saleforce

Manual realizado por Proyecto Tribo

CONTENIDOS DEL DOCUMENTO

INTRODUCCIÓN

OBJETOS

  1. Configuración:

  2. ¿Qué monitorear en el TC Panel de Control?

  3. ¿Qué información encontrás en TC Pagos?

  4. ¿Qué es TC Error Logs?

ESTADOS DE TC PAGOS

  1. Estados posibles

TC MÉTODO DE PAGO

  1. ¿Cómo crear un TC Método de Pago?

  2. ¿Qué se hace si se necesita modificar los datos del número de método de pago?

PROCESO DE PAGOS

INTRODUCCIÓN​

Este documento brinda información sobre la integración entre Debi (anteriormente llamado TuCuota) y Salesforce. Esta integración se va a generar a partir de un objeto personalizado llamado “TuCuotaPago” que funcionará de puente entre Salesforce y Debi. A partir de este objeto, se generan los TC Pagos de cada oportunidad mensual en estado comprometida y estos son enviados directamente a Debi para ser procesado. Este a su vez devolverá sincrónicamente a Salesforce la respuesta positiva o negativa de recepción del pago, es decir que devolverá el estado del pago luego de procesado.

De esta manera cada Oportunidad en Salesforce que cumpla con las condiciones mencionadas generará un pago en Tu Cuota.

La integración prevé adicionalmente la creación de métodos de pago de cada donante de manera de garantizar la seguridad de la transacción. Estos métodos de pago permiten almacenar de manera segura la información de los números de medio de pago (tarjeta de crédito, débito o CBU).

OBJETOS​

Configuración: ​

  1. TC Panel de Control: Será la ficha que permite saber el estado de la integración de Debi en Salesforce (Estado autenticado - No autenticado).
  2. TC Pagos: Será el objeto central que se integra en ambos sistemas. Este objeto permite llevar un control de las oportunidades a procesar y el estado de las mismas luego de procesadas.
  3. TC Error Logs: Será el objeto donde se podrán monitorear los errores de la integración. Por ejemplo, errores de validación.
  4. TC Métodos de Pago: Será el objeto donde se almacenarán los métodos de pago de cada donante.

¿Qué monitorear en el TC Panel de Control?​

En este objeto se monitorea el estado de la integración de Debi en Salesforce (Estado autenticado - No autenticado).

manual

¿Qué información encontrás en TC Pagos?​

  • Nombre del TC Pagos: por ejemplo TCP-2222.
  • Monto a cobrar al medio de pago (tarjeta de crédito, de débito o CBU).
  • Nombre de la oportunidad. Este campo no es obligatorio que esté en TC Pagos.
  • Cliente: es decir el contacto. Es importante que sea un contacto ya cargado en Salesforce.
  • TC Métodos de Pago: Método de pago del donante tokenizado por Debi. Ver cómo crear un TC Método de Pago.
  • Estado: ver Estados posibles.
  • Fecha estimada de acreditación: La fecha estimada de acreditación se calcula sumando días hábiles desde el día en que se aprueba el pago según los distintos plazos de liquidación.
  • Fecha de cobro: la fecha en que Debi va a intentar cobrar la donación.
  • Fecha de cobro efectiva: la fecha real de cobro.
  • Reintentar hasta: fecha hasta la que se reintenta en la tarjeta.
  • Pagado: se marca con un tilde cuando el TC Pagos esté cobrado.
  • Se pueden ver también datos de la respuesta del proceso de cobro, especialmente el mensaje de error.

manual

¿Qué es Debi Error Logs?​

Debi Error Logs es el objeto desde donde se podrán monitorear los errores de la integración. Por ejemplo, errores de validación. En este objeto se verán las novedades, es decir, todas las veces que Salesforce y Debi intercambiaron información, qué información se envió y qué información volvió.

manual

ESTADOS DE TC PAGOS​

Estados posibles​

  • Pendiente de envío: El pago se crea en este estado. La TC Pagos todavía no pasó a Debi para ser procesado. En esta etapa aún puede cancelarse la Oportunidad o realizar cambios en el monto, el método de pago y la fecha de cobro, sin embargo hay que tener en cuenta que en este estado sólo está unos minutos y luego pasa a “Enviado sin procesar”.
  • Enviado sin procesar: Estado automático. La oportunidad fue enviada a Debi, pero Debi todavía no la procesó. En este estado aún pueden modificarse el monto, el método de pago y la fecha de cobro.  Además en este estado puede pasar a “Enviado a Cancelar” para que Debi no lo cobre. Queda pocos segundos en “Enviado a Cancelar” y pasa a “Cancelado”.
  • Enviado en proceso: Estado automático. Debi envío el pago al medio de pago para su cobro. A partir de este momento no se puede cancelar, ni cambiar el monto, el método de pago y la fecha de cobro.
  • Aprobado: Estado automático. El pago fue cobrado con éxito.
  • Rechazado:  Estado automático. Rechazado en Tu Cuota luego de procesar. El pago no pudo ser cobrado.
  • Devuelto: Estado automático. Alguien pidió la devolución de un pago. Ver ¿Cómo funciona el estado “Devuelto”?
  • Con Error: Estado automático. Volvió con error en la comunicación con Debi. El pago nunca llegó a tu cuota, por lo que no pudo ser cobrado, ni enviado a procesar. Por ejemplo , porque hubo un error en la integración.
  • Enviado a cancelar: Cuando se elimina una oportunidad o se pierde una oportunidad, y el TC Pago relacionado estaba en Pendiente de envío o Enviado sin procesar, el TC Pagos pasa al estado Enviado a cancelar y se envía a Debi a cancelar.
  • Cancelado: Estado automático. Si el TC Pagos enviado a cancelar se cancela con éxito, el estado pasa a “Cancelado”.
  • Reintentando: Debi está reintentando el cobro.

Correspondencia de estados​

SaleforceDebi
Pendiente de envíoEstado temporal hasta que llegue a Debi
Enviado sin procesarPendiente de envío (pending_submission)
Enviado en procesoEnviado (submitted)
AprobadoAprobado (approved)
RechazadoRechazado (rejected)
DevueltoDevuelto (chargeback)
Con errorNo existe en Debi
Enviado a cancelarEstado temporal hasta que se cancela
CanceladoCancelado (cancelled)
ReintentandoEn proceso de reintento en Debi

MAPA DE ESTADOS

TC MÉTODO DE PAGO​

¿Cómo crear un TC Método de Pago?​

1. Proceso manual​

Los métodos de pago se crean desde el contacto.

En el caso de que se cree una oportunidad de única vez, el TC Método de Pago debe seleccionarse en la oportunidad y luego pasará la información automáticamente al TC Pago relacionado.

manual

IMPORTANTE:

Recordar siempre seleccionar “Procesado con: TuCuota” para activar la creación de los TC Pagos.

Pasos a seguir para crear un TC Método de Pago:

a. Se debe ingresar el número de método de pago (tarjeta o CBU). El mes y el año de vencimiento será requerido sólo en países que lo exijan para  el caso de las tarjetas. b. Luego, hacer click en “Enviar”. c. En relacionado del contacto se pueden visualizar los métodos de pago del contacto. Cada contacto puede tener más de un método de pago.

manual

d. Una vez creado el método de pago, se debe crear la donación recurrente u oportunidad de única vez y seleccionar como procesador de pago “TuCuota” y el TC Método de pago elegido de ese contacto.

manual

2. Proceso automático​

IMPORTANTE:

Este método requiere una solicitud para que podamos instalarlo, ya que no está incluido en el paquete.

Los métodos de pago se crean desde la Oportunidad o Donación Recurrente.

  • Al ingresar o modificar el número de método de pago (tarjeta o CBU), se crea automáticamente un nuevo TC Método de Pago y se reemplaza al que estaba relacionado previamente.
  • Además, las oportunidades sueltas (aquellas no asociadas a una donación) se tokenizan automáticamente de la misma manera que las donaciones recurrentes.
  • Si se deja vacío el número de tarjeta, el TC método de pago se borrará.

manual

¿Qué se hace si se necesita modificar los datos del número de método de pago?​

IMPORTANTE:

Corresponde al proceso manual.

En el caso que se necesita modificar los números de tarjeta de crédito o CBU, se debe crear un NUEVO TC Métodos de Pago:

  1. Se debe crear desde el contacto un NUEVO TC Métodos de Pago.
  2. Una vez creado el nuevo TC Métodos de Pago, debe actualizarse en la donación recurrente o en la oportunidad de única vez el campo TC Métodos de Pago con el nuevo TC Métodos de Pago creado.

PROCESO DE PAGOS​

Nueva donación recurrente u oportunidad​

  1. Los TC Pagos pueden crearse tanto para oportunidades creadas a partir de donaciones recurrentes como para oportunidades de única vez.
  2. Cuando una Oportunidad está en estado “Comprometida” (1) y el procesador de pago es “TuCuota” se genera un TC Pagos en estado Pendiente de Envío. La información de los TC Pagos puede visualizarse en relacionado de la Oportunidad (2).
  3. Cuando se crea un TC Pagos, se marca en la oportunidad el campo TC Pagos creado. De esta forma se asegura que no se creen por error dos pagos en la misma oportunidad.

manual

  1. El estado Pendiente de Envío dura solo unos minutos, luego de lo cual pasa a Enviado sin procesar. La integración entre las dos plataformas busca cada 5 minutos aproximadamente nuevas oportunidades.
IMPORTANTE:

En esta etapa SI pueden realizarse cambios en el monto o en el TC Métodos de Pago o  enviarse para cancelar.

  1. Una vez que se llega a la fecha de cobro, el pago se procesa, pasando a la etapa Enviado en proceso.
IMPORTANTE:

En esta etapa NO pueden realizarse cambios en el monto o en el TC Métodos de Pago, NI enviarse para cancelar.

  1. Una vez procesado el pago el estado se actualizará según se haya procesado correctamente o no.

a) Si se cobra (Oportunidad Cerrada Ganada) pasa a Aprobado.

b) Si no se puede cobrar (Oportunidad Cerrada Perdida) pasa a:

  • Rechazado: Rejected en Tu Cuota.
  • Devuelto: Se devuelve el pago a pedido del donante.

Manejo de Donaciones Únicas en Legacy Recurring Donations:

Problema: En el sistema Legacy Recurring Donations de Salesforce, estamos enfrentando un problema significativo con las donaciones únicas. Salesforce crea y borra repetidamente la misma oportunidad antes de crear la oportunidad definitiva. Sin embargo, el borrado ocurre a un nivel que no es detectado por un trigger, lo que resulta en la cancelación del TC Pago debido a un bug en el NPSP legacy.

Solución Propuesta: Para gestionar esta situación y evitar problemas con la creación y eliminación errática de oportunidades, es necesario seguir estos pasos:

- Evitar el Uso de Donaciones No Recurrentes en Legacy:

  • No utilizar el sistema Legacy Recurring Donations para registrar donaciones únicas.
  • Reconocer que el motor de creación de oportunidades en legacy es inestable para donaciones no recurrentes.

- Crear Oportunidades Sueltas:

  • Las organizaciones que utilizan el sistema legacy deben gestionar las donaciones únicas creando oportunidades sueltas directamente.
  • No utilizar el objeto de donación para registrar donaciones de única vez.

¿Cómo modificar una donación recurrente u oportunidad?​

Se puede modificar el monto o el TC Métodos de Pago cuando está en estado “Pendiente de Envío” o “Enviado sin procesar”.

Si el cambio es de monto o TC Métodos de Pago este cambio debe realizarse en la donación recurrentes y luego se actualiza automáticamente la oportunidad y el TC Pago.

Si lo que se quiere cambiar es la fecha de cobro ese cambio debe realizarse en la oportunidad.

IMPORTANTE:

Una donación recurrente u oportunidad SI puede modificarse en estado “Pendiente de Envío” o “Enviado sin procesar”. NO pueden modificarse cuando están en estado “Enviado en proceso”.

Effective Date en modificaciones del mes en curso

El campo Effective Date se utiliza para indicar desde qué fecha se hace efectivo un cambio en la donación recurrente.

  • Si el cambio debe impactar en la oportunidad del mes en curso, el Effective Date debe coincidir con la fecha de la oportunidad existente (por ejemplo, 1/1/2025).
  • Si se establece una fecha posterior (como 4/1/2025), el cambio solo impactará en las oportunidades programadas a partir de esa fecha.

Esta es una funcionalidad específica de Enhanced Recurring Donations (RRDD).

¿Qué hay que tener en cuenta cuando se actualizan las Oportunidades (Upgrades)?​

Hay que destacar un aspecto importante sobre el paquete: los pagos se enviarán a las entidades antes de que comience el mes, específicamente en los casos de Visa Débito y CBU. Esto implica que nuestras oportunidades están configuradas para ser cobradas el día 1 del mes. Sin embargo, con respecto a CBU y Visa Débito, debemos enviar las presentaciones dos días hábiles antes y un día hábil antes de esa fecha, respectivamente.

Por lo tanto, es de vital importancia que siempre verifiquen y realicen cualquier upgrade antes de que se envíen estas presentaciones.

¿Cómo cancelar una oportunidad?​

Si una oportunidad se elimina o se pasa a “Cerrada Perdida” antes de que pase al estado “Enviado en proceso”, el pago se puede cancelar.

El sistema de forma automática pasará el pago a “Enviado a cancelar”, Debi cancela el pago y actualiza el estado  a “Cancelado”.

IMPORTANTE:

Una oportunidad SI puede cancelarse en estado “Pendiente de Envío” o “Enviado sin procesar”. NO puede cancelarse cuando está en estado “Enviado en proceso”.

IMPORTANTE:

Tener en cuenta que si se modifica la plataforma de Pago en las Donaciones Recurrentes u Oportunidades, de TuCuota a otro medio, se debe cancelar el TC Pago de manera manual ya que estos casos no se detectan en los flujos automáticos.

¿Qué pasa cuándo un TC pago vuelve con el estado rechazado?​

En este caso Debi SI procesó el pago pero NO pudo ser cobrado.

Si el TC Pagos es de este mes y quieren volver a enviarla a TuCuota porque cambiaron algún valor, se debe hacer click en el botón “Reenviar pago” dentro de la Oportunidad.  Esta acción crea un nuevo TC Pagos.

manual

Solo puede enviar a “Reenviar pago” una oportunidad de este mes o siguientes, no pueden enviarse una oportunidad del mes pasado.

No pueden enviar a “Reenviar pago” oportunidades en estado Cerradas Ganadas.

¿Cómo funciona el estado “Devuelto”?​

No modificamos el estado de la Oportunidad que ya está en etapa ganada en los casos devueltos, porque no hay una acción única que se pueda presentar:

Ejemplos:

  1. Duplicado de Pago:

    • Puede haber un pago duplicado. En este caso, uno de los pagos fue exitoso y marcó la oportunidad como ganada. El otro pago, aunque devuelto, no afectó el estado de la oportunidad.
    • Si se confirma que es un duplicado, la oportunidad debería mantenerse en estado ganada.

  2. Cobro Incorrecto:

    • Puede haber un cobro que no debería haberse realizado y luego fue devuelto.
    • En este escenario, la oportunidad debería cambiarse a perdida, ya que el cobro original no fue válido.

¿Qué monitorear?​

ACTUALIZACIÓN:

Compartimos el siguiente artículo donde podremos ver los paneles agregados y la información que contiene cada informe.

Almacenamiento​

El paquete en sí no consume espacio de su quota. Sin embargo, es importante tener en cuenta que los registros generados durante el uso del paquete sí consumirán espacio.

A modo de referencia, se genera 1 registro de "TC Método de Pago" por cada Donación Recurrente o por cada cambio de tarjeta. Esta cantidad no representa un consumo significativo. Asimismo, se genera 1 registro de "TC Pago" por cada oportunidad. Los registros de "TC Pago" de varios meses atrás pueden ser borrados, ya que cumplen una función en el proceso de cobro, pero no es necesario mantener un archivo histórico de los mismos. Cada registro creado consume 2 kb, por lo tanto, una estimación aproximada indica que en 6 meses podrían generarse alrededor de 25.000 registros de "TC Método de Pago" y 120.000 registros de "TC Pago", ocupando aproximadamente 300 Mb, lo cual representa un 2% de su quota total de 10 Gb.

Para controlar la cantidad de registros y el porcentaje utilizado, pueden acceder a Configuración - Datos - Uso de Almacenamiento:

almacenamiento

Gestión de Donaciones Únicas en NPSP Legacy​

  1. Manejo de Donaciones Únicas en Salesforce Legacy

En la versión Legacy de Salesforce, específicamente al utilizar el sistema NPSP (Nonprofit Success Pack), es necesario gestionar las donaciones únicas mediante el objeto Oportunidades sueltas. Esto se debe a un comportamiento problemático en el objeto Legacy Recurring Donations, donde el sistema realiza la siguiente secuencia de eventos al intentar registrar una donación única:

  • Salesforce crea y elimina repetidamente la misma oportunidad antes de generar la oportunidad definitiva.
  • El proceso de eliminación es tan rápido que no es detectado por los triggers, y así llegar a cancelar el TC Pago, debido a un bug conocido en el sistema NPSP Legacy.

Recomendación: Para evitar este error, se aconseja no utilizar donaciones no recurrentes dentro del objeto Legacy Recurring Donations. En su lugar, todas las donaciones únicas deben ser gestionadas como Oportunidades sueltas en el objeto Oportunidades. Además, es crucial migrar todas las donaciones únicas preexistentes a este formato para evitar futuros errores.

almacenamiento

  1. Fechas de Oportunidades en Salesforce Legacy

En el sistema Legacy, las fechas de las oportunidades se determinan en función de la fecha de creación de la donación original. Esto afecta cómo se generan las futuras oportunidades. Los ejemplos a continuación ilustran este comportamiento:

  • Si una donación fue creada el 1 de marzo de 2019, todas las oportunidades futuras se generarán el día 1 de cada mes.
  • Si una donación fue creada el 25 de marzo de 2019, todas las oportunidades futuras se generarán el día 25 de cada mes.

Recomendación: Es recomendable establecer el día 1 como fecha para la creación de oportunidades, con el fin de mantener consistencia y minimizar errores en la generación de futuras oportunidades. Asegurarse de seguir esta práctica en todas las donaciones ayuda a evitar conflictos de sincronización.

Gestión de Cuentas y Contactos en Salesforce​

Para mejorar la administración de contactos y cuentas, se recomienda seguir estos pasos:

  1. Crear Cuentas de Tipo 'Household' para Contactos Individuales:

    • En lugar de utilizar una sola cuenta como contenedor de todos los contactos, cada individuo debe asociarse a su propia cuenta Household.
    • Ejemplo: Un contacto llamado "Juan Pérez" debería tener una cuenta 'Household' con el nombre "Familia Pérez Household".
    • Esto permite manejar los contactos de manera independiente y evita la agrupación masiva de todos en una sola cuenta.

  2. Utilizar Cuentas de Tipo 'Organización' para Instituciones o Empresas:

    • Las cuentas de tipo "Organización" deben usarse únicamente para agrupar contactos que pertenezcan a instituciones o empresas (no para individuos).
    • Cuando un contacto necesita estar vinculado a una organización (por ejemplo, un donante que también es voluntario de una institución), se debe crear una afiliación (o relación) entre el contacto y la cuenta de tipo "Organización".

  3. Evitar el Uso de Cuentas como Agrupadores:

    • Para clasificar o agrupar contactos, es mejor utilizar campos personalizados en el registro de contacto. Ejemplo: crear un campo llamado "Categoría de Contacto" donde se pueda seleccionar valores como "Donante", "Voluntario", etc.
    • No utilicen una cuenta única como contenedor de agrupación, ya que esto genera problemas de rendimiento y límites en Salesforce.

  4. Configurar Múltiples Roles para Contactos:

    • Si un contacto necesita tener más de un rol (como "Donante" y "Voluntario"), utilicen el sistema de afiliaciones en lugar de asignarlo a múltiples cuentas.
    • Las afiliaciones permiten que un contacto esté asociado con diferentes cuentas o roles, sin necesidad de duplicar su cuenta o hacer agrupaciones innecesarias.

  5. Mantener la Integridad de Datos:

    • Cada contacto debe tener solo una cuenta principal, que generalmente será su Household.
    • Cuando es necesario vincularlo con otras organizaciones o instituciones, se debe realizar mediante afiliaciones y no añadiendo el contacto a otra cuenta.
      Nota Importante

      No se recomienda eliminar cuentas de contactos a menos que se haya realizado un respaldo, ya que esto podría borrar todos los registros relacionados sin recuperación posible.

Riesgos y Consecuencias del Mal Manejo de Cuentas en Salesforce​

  1. Superación de Límites en NPSP: Continuar agrupando todos los contactos en una cuenta única llevará rápidamente a superar los límites de registros de Salesforce, afectando la velocidad de procesamiento y la capacidad de modificación de registros.

  2. Posibilidad de Pérdida de Datos Irreversible: Si se elimina la cuenta principal, todos los contactos y datos asociados también serán eliminados, sin capacidad de restauración.

  3. Problemas en los Reportes y Funcionalidades: La estructura actual impide generar reportes precisos y dificulta la gestión de oportunidades y campañas.

  4. Impacto en la Integridad de las Oportunidades: Las oportunidades vinculadas a cuentas incorrectas pueden causar errores en los reportes financieros y en la administración de donaciones, afectando la confiabilidad de los datos para la organización.

Ejemplo de Estructura Correcta de Cuentas y Contactos​

Para aclarar el manejo correcto de cuentas y contactos, aquí se muestra un ejemplo sencillo:

  • Contacto Individual: Juan Pérez
    • Cuenta: Familia Pérez Household
    • Afiliaciones:
      • Voluntario en "Fundación Manos Unidas" (cuenta de tipo "Organización")
      • Donante mensual en "Asociación Esperanza" (cuenta de tipo "Organización")

Configuración de Intentos de Cobro hasta el 25 de Cada Mes​

¿Por qué los reintentos de pagos se detienen el día 25 de cada mes?​

Los pagos en las ONG integradas con Debi están configurados para reintentarse hasta el día 25 de cada mes. Esto se debe a varias razones importantes:

  1. Cantidad de intentos:
    Generalmente, para cada transacción fallida se realizan hasta 7 intentos de cobro. Esta cantidad asegura que se hayan agotado las posibilidades razonables de recuperar el pago antes de detener los reintentos.

  2. Evitar cobros consecutivos:
    Reintentar después del día 25 podría generar situaciones donde dos cuotas (o pagos recurrentes) queden demasiado próximas, especialmente en el caso de tarjetas Visa Débito. Estas se procesan un día hábil antes del final del mes, lo que podría causar confusión o inconvenientes para el donante.

  3. Respuestas tardías de las entidades:
    Algunas respuestas de las entidades bancarias o procesadoras de pagos pueden llegar después del fin de mes, lo que puede causar que los cobros se registren en el mes siguiente. Esto puede afectar la contabilidad y la planificación de los donantes y de la ONG.

Configuración Estándar​

Esta configuración está implementada de forma estándar en todas las ONG que trabajan con Debi, asegurando un manejo ordenado y consistente de los intentos de cobro.

Pausar Donaciones Recurrentes en Salesforce​

1. Función de Pausar Donaciones Recurrentes La función de pausa permite detener temporalmente la generación de oportunidades relacionadas con una donación recurrente sin cancelar el compromiso del donante. Esta funcionalidad es recomendable ya que conserva el ciclo de donación intacto y evita la necesidad de recrear oportunidades o sus Debi Pagos.

2. Acceso a la Opción La opción para pausar donaciones recurrentes se encuentra en el objeto Donación Recurrente o Recurring Donation en Salesforce.

  1. Navega al registro de la donación recurrente que deseas pausar.
  2. Busca el botón o campo "Pausar Donación" o equivalente.
  3. Configura el período de pausa, indicando:
    • Fecha de inicio de la pausa.
    • Fecha de reanudación (opcional).

Nota: Si no ves esta opción, asegúrate de que tu perfil tenga los permisos necesarios para gestionar donaciones recurrentes.

3. Comportamiento al Pausar Donaciones

  • Oportunidades Existentes:

    • Si ya hay una oportunidad generada para la donación recurrente, esta no se cancela.
    • Su fecha de cierre proyectada se ajusta automáticamente al próximo mes o al período definido en la pausa.

  • Debi Pago:

    • El Debi Pago asociado a la Oportunidad se ajusta al nuevo período definido.
    • Esto asegura que el Pago se reanude automáticamente en la fecha correcta sin necesidad de recrearlo.

  • Nuevas Oportunidades:

    • Durante el período de pausa, no se generan nuevas oportunidades hasta que la donación recurrente vuelva a estar activa.

  • Estado de la Donación Recurrente:

    • El estado del registro de la donación recurrente cambia a algo como "Pausada" o equivalente, dependiendo de la configuración.

4. Comportamiento al Reactivar Donaciones

  • Oportunidades Existentes:

    • La oportunidad que fue ajustada en su fecha de cierre durante la pausa se vuelve activa automáticamente al reanudar la donación recurrente.
    • No es necesario crear una nueva oportunidad ni modificar el Debi Pago asociado.

  • Nuevas Oportunidades:

    • Salesforce reanuda la creación de oportunidades desde la fecha de reactivación según el cronograma habitual.

5. Ventajas de Usar la Función de Pausar Donaciones

  • Evita Cancelaciones:
    Al pausar la donación recurrente, el ciclo de donación permanece intacto y no es necesario recrear oportunidades ni sus Pagos asociados.

  • Automatización Eficiente:
    El ajuste automático de fechas garantiza que tanto las oportunidades como los Pagos se reanuden en el momento adecuado.

Recomendación: Siempre usa la opción de pausar la Donación Recurrente y no la oportunidad individual, para que el sistema gestione correctamente las fechas.

6. Ruta de Configuración Para gestionar las configuraciones relacionadas con donaciones recurrentes:

  • NPSP Settings:
    Ve a NPSP Settings > Recurring Donations para verificar la configuración del comportamiento estándar de las donaciones recurrentes.

Ejemplo:

paused

paused

paused

paused

paused

paused