Formularios

From SinergiaCRM - Wikisuite
Jump to navigation Jump to search

Introducción

Los formularios web son uno de los canales habituales a través de los que una entidad recibe información de su base social: donativos, altas de socios, recogidas de firmas, suscripciones a boletines electrónicos, inscripciones a eventos, etc.

Que la información recibida por esta vía quede directamente incorporada al CRM de la entidad supone unos beneficios notables puesto que evita cualquier proceso de traspaso o de registro manual de los datos recibidos y mejora la calidad de la información que entra en la aplicación al poder aprovechar los mecanismos de detección de duplicados y otras funcionalidades del sistema.


A pesar de que la creación de formularios está vinculada a determinados módulos concretos del CRM como Campañas o Eventos se ha considerado oportuno agrupar toda la información relativa a los mismos en esta página, teniendo en cuenta que los procesos de generación y los usos de los diferentes formularios son similares aunque manejen diferente información.

Actualmente existen tres tipos distintos de asistentes de creación de formularios en SinergiaCRM:

1. Formulario básico de campañas: vinculado a los módulos de Personas, Interesados y Público objetivo, para recibir datos de primer contacto con la entidad (suscripción a boletines, interés en voluntariado, etc.). En el CRM es el llamado Formulario web de persona.

2. Formulario de inscripción a un evento: vinculado a los módulos de Eventos e Inscripciones, para facilitar la inscripción de personas a eventos organizados por la entidad.

3. Formulario de captación de fondos: vinculado al módulo de Compromisos de pago, para recibir donaciones, altas de socios y, en general, cualquier tipo de colaboración económica con la entidad.

En nuestro canal de Youtube tenéis a vuestra disposición un vídeo formativo sobre formularios.



Creación de un formulario

Aunque cada tipo de formulario presenta sus propias particularidades, son varias las pantallas compartidas entre los diferentes asistentes. En la siguiente sección se encuentra la explicación de dichas pantallas comunes y, más adelante, se explican paso por paso todos los asistentes.

Pantallas comunes a todos los formularios

Añadir o quitar campos al formulario

Para incorporar un campo al formulario basta con arrastrarlo y soltarlo desde la columna de la izquierda a cualquiera de las dos columnas del lado derecho. Por el contrario, si se quiere eliminar un campo del formulario basta con arrastrarlo y soltarlo en la columna de la izquierda.


Formularios.jpg


Existe la posibilidad de ordenar alfabéticamente la lista de campos pulsando sobre el rótulo Campos disponibles.

El botón Agregar todos los campos permite añadir todos los campos de una sola vez. De todos modos, raramente va a ser necesario utilizarlo.


Campos obligatorios

En los formularios de captación de fondos y de inscripción a eventos, al acceder a la pantalla de selección de campos, los que sean obligatorios (marcados con un asterisco en el interfaz) aparecerán directamente en la primera columna del formulario. Es importante tener en cuenta que los campos obligatorios deben ser incluidos en el formulario. De no hacerlo aparecerá un mensaje de error informando de los campos faltantes.

Obligatorios.jpg

Cabe indicar que los campos obligatorios lo son en la medida en que así se indica en su configuración en Estudio. Así pues, el asistente de creación de formularios se basa en dicha información para identificar qué campos son obligatorios y, por lo tanto, requerir su inclusión en los formularios. En este sentido, si un usuario administrador desactiva en Estudio la condición de obligatorio de un campo, el formulario podrá generarse sin que sea necesario incluir dicho campo. Sin embargo, conviene tener presente que algunos campos (como Apellidos) siempre serán requeridos por parte del CRM cuando le lleguen datos procedentes de un formulario web, por lo que conviene no desactivar su obligatoriedad y así asegurar que siempre serán incluidos en los formularios.


Formatear la apariencia del formulario

Antes de descargar el formulario es posible modificar su apariencia mediante las herramientas de edición que se encuentran justo encima del formulario.

Cabe tener en cuenta, además, que en el paso final el CRM ofrecerá el código HTML resultante, el cual puede ser reeditado utilizando cualquier otra herramienta antes de incorporarlo al sitio web correspondiente. De hecho, lo más habitual será que la adecuación estética se resuelva mediante la aplicación de las hojas de estilo del sitio web en el que se vaya a alojar el formulario.


Formularios3.jpg


Pantalla de descarga del resultado del formulario

La pantalla final del formulario permite descargar [1] el formulario en forma de documento HTML o copiar directamente el código fuente del área de texto [2] que se muestra en la pantalla. Este código deberá ser incorporado al sitio web correspondiente.


Formularios5.jpg


Es importante verificar que el código HTML generado por el CRM se traslada íntegramente al sitio web. Es frecuente que determinados gestores de contenidos (CMS) de uso habitual como Wordpress, Joomla o Drupal eliminen partes del código (particularmente de javascript) por razones de seguridad. Si es el caso deberán tomarse las medidas oportunas para evitarlo, ya sea configurando adecuadamente los permisos en los editores, ya sea mediante la incorporación de plugins que lo faciliten, etc.


Formulario básico de campañas

¿Cómo se accede?

A través del asistente Crear formulario web de Persona, accesible desde el menú de acciones del módulo Campañas.

Formulario0.jpg

Paso 1

El punto de partida será seleccionar el módulo base del formulario web que vamos a generar. Esto supondrá que el asistente nos mostrará los campos de este módulo para que podamos añadir aquellos que consideremos al formulario, y que una vez tengamos el formulario online, cuando un usuario lo rellene y envíe, los datos serán almacenados en un nuevo registro del módulo base seleccionado.

El funcionamiento de la pantalla está explicado en la sección Añadir o quitar campos al formulario

Paso 2

A continuación se definen las características generales del formulario:

- la cabecera (o título)

- los textos de descripción del formulario, para la etiqueta del botón de envío y del pie del formulario.

- las URLs de envío o de redirección (en el caso de la URL de redirección se trata de la página que se mostrará al inscrito cuando haya finalizado el proceso).

Cualquier entidad que tenga alojado el CRM en los servidores de SinergiaTIC debe editar la URL de Envío (activando la casilla que aparece a la derecha de este campo) añadiendo una letra "s" a "http", para dejarlo como "https". Esto es así porque los servidores de SinergiaTIC utilizan el protocolo seguro "https" para que los datos viajen encriptados por la red. Si no se realiza este cambio, al cumplimentar un formulario el CRM responderá con un mensaje del tipo "El servidor no está disponible en estos momentos".

- la campaña (previamente creada) para el que se genera el formulario.

- el usuario gestor interno (campo Asignado a).


Formularios2.jpg


A diferencia de los asistentes de generación de formularios de Inscripción a eventos y de Captación de fondos, el asistente de generación de formularios básicos de Campañas no permite indicar la posibilidad de incluir ficheros adjuntos en el formulario. En caso de que se desee incorporar uno o más campos de tipo upload en el formulario, deberá hacerse manualmente. Para más información consultar el apartado Añadir campos upload para archivos adjuntos en formularios básicos de campañas.

Paso 3

Este paso permite editar la apariencia del formulario antes de su descarga. Para más información consultar la sección Formatear la apariencia del formulario

Paso 4

El último paso del formulario permite obtener el código HTML resultante. Para más información consultar la sección Pantalla de descarga del resultado del formulario.


Formularios de inscripción a un evento

¿Cómo se accede?

A través del asistente Formulario web de inscripción a un evento, accesible desde el menú de acciones del módulo Eventos.


Formularios6.jpg


Paso 1

El formulario de inscripción a un evento permite incluir datos de diferentes módulos de manera simultánea e incorporar o no el sistema de pagos online. En este primer paso se indican los módulos a incluir así como el comportamiento de algunos campos concretos.


Formularios7.jpg


1. Incluir el sistema de pagos: si se marca esta casilla el asistente incluirá los campos necesarios para gestionar el cobro de la inscripción.

2. Incluir datos de la Organización: marcando esta casilla el asistente mostrará un paso más en el que podremos seleccionar los diferentes campos del módulo de Organizaciones que se desee incluir.

3. Hacer opcional el campo Nombre de la Organización: esta casilla sólo se podrá activar cuando la casilla de Incluir datos de la Organización esté activada y cuando no se haya activado la casilla de Hacer el Número de identificación obligatorio. Esta opción permite incluir datos de Organización en el formulario de manera que sea opcional para el usuario final rellenar la información sobre la Organización, de manera que únicamente se procesaran datos de la Organización si vienen informados, en caso contrario, se obviarán.

4. Hacer el Número de identificación obligatorio: esta casilla sólo se podrá activar cuando la casilla de Incluir datos de la Organización esté activada. Implica que el campo Número de identificación será obligatorio en el formulario generado, lo cual tiene implicaciones en la búsqueda de duplicados en el momento de recibir los datos. Para más información consultar la sección Recepción de datos - Formulario de inscripción a un evento. Marcar esta opción implica que deberemos, forzosamente, recibir datos de la Organización, de manera que la casilla anterior de desmarcará automáticamente y el campo Nombre de la Organización volverá a ser obligatorio.

5. Incluir los datos de la inscripción: marcando esta casilla el asistente mostrará un paso más en el que podremos seleccionar los diferentes campos del módulo Inscripciones que se desee incluir. Esto es especialmente útil cuando se desea solicitar información relativa a la participación de la persona que se va a inscribir en el evento como por ejemplo necesidades especiales, actividades del evento a las que asistirá, etc. El campo Fecha de inscripción se rellenará automáticamente con la fecha del día en el que se envía el formulario por lo que no aparecerá listada entre los campos a añadir al formulario.

Paso 2

Este paso nos permite seleccionar los campos del módulo Personas que se desee incluir en el formulario. El funcionamiento de la pantalla está explicado en la sección Añadir o quitar campos al formulario.

Paso 3 (Opcional)

Este paso únicamente será visible si se ha marcado la casilla Incluir datos de la Organización en el paso 1. Permite seleccionar los campos del módulo Organizaciones que desee incluir en el formulario. El funcionamiento de la pantalla está explicado en la sección Añadir o quitar campos al formulario.

Paso 4 (Opcional)

Este paso únicamente será visible si se ha marcado la casilla Incluir datos de la Inscripción en el paso 1. Permite seleccionar los campos del módulo Inscripciones que desee incluir en el formulario. El funcionamiento de la pantalla está explicado en la sección Añadir o quitar campos al formulario.

Paso 5

En este paso se definen algunos parámetros necesarios para el funcionamiento del formulario.


Formularios8.jpg


  1. Cabecera: título que aparecerá en el formulario.
  2. Descripción: texto que aparecerá entre el título y los campos del formulario. Permite incluir una descripción del formulario o un texto de ayuda, por ejemplo.
  3. Etiqueta del botón Enviar: permite modificar la etiqueta de visualización del botón Enviar del formulario generado.
  4. URL de envío Post: es la dirección URL a la que se enviará la petición del formulario. El asistente para este tipo de formularios intentará detectar el tipo de conexión usado por SinergiaCRM en la instancia de la entidad (http o https) y adaptar la dirección a dicho tipo de conexión. Así pues, es posible que, a diferencia de otros formularios, no se deba modificar este valor, aunque sí es recomendable revisar que el tipo de conexión coincida con el detectado.
  5. Editar: permite editar la URL de envío Post por si hubiera que realizar algún cambio.
  6. Importe: únicamente aparecerá si se ha marcado la casilla Incluir el sistema de pagos en el paso 1. El importe de una inscripción puede venir fijado en el propio formulario o bien dejar que sea el usuario final del formulario quien introduzca un importe. Dejando este campo vacío el asistente generará un campo de texto que permita al usuario introducir un valor numérico. Por el contrario, si se indica un valor en este campo el valor del importe quedará fijado y no se generará ningún campo de texto.
  7. Tipo de pago: únicamente aparecerá si se ha marcado la casilla Incluir el sistema de pagos en el paso 1. Permite definir qué tipo de pago se generará con cada petición que llegue a través del formulario. Los valores de este desplegable se adaptan a los valores indicados para el campo Tipo de pago del módulo Compromisos de pago.
  8. URL de redirección: es la URL donde se redirigirá al usuario en caso de que la petición se haya realizado con éxito. Este campo es obligatorio ya que las pasarelas de pago requieren una dirección de reenvío tanto en caso de éxito como de error. Normalmente será una página del sitio web donde se encontraba el formulario.
  9. URL de redirección en caso de error: siguiendo la mismo lógica que el anterior punto, indica la URL de redirección en caso de que haya ocurrido algún error durante la gestión de la petición. Normalmente será una página del sitio web donde se encontraba el formulario.
  10. Plantilla de correo de notificación al usuario que se inscribe: opcionalmente se puede indicar una plantilla de correo para enviar una notificación al usuario conforme la operación se ha realizado (ver sección Notificación a la persona inscrita/donante mediante plantillas de correo). Si no se indica ninguna plantilla no se le enviará ninguna notificación.
  11. Evento relacionado: todos los formularios de inscripción a eventos deben estar, lógicamente, vinculados a un evento.
  12. Asignado a: permite indicar qué usuario de SinergiaCRM se hará cargo de la gestión del formulario (por defecto será el usuario activo). Este campo es especialmente importante ya que para cada petición que llegue desde el formulario se enviará un correo electrónico a este usuario informando de los datos recibidos y el resultado de la operación (más información en Recepción de datos - Formulario de inscripción a eventos).
  13. Pie del formulario: permite añadir un texto que aparecerá en la parte inferior del formulario.
  14. Número de ficheros adjuntos: permite incorporar al formulario campos de tipo upload (hasta un máximo de 5) para enviar archivos adjuntos al CRM.

Paso 6

Este paso permite editar la apariencia del formulario antes de su descarga. Para más información consultar la sección Formatear la apariencia del formulario.

Paso 7

El último paso del formulario permite obtener el código HTML resultante. Para más información consultar la sección Pantalla de descarga del resultado del formulario.


Formularios de captación de fondos

¿Cómo se accede?

A través del asistente Nuevo formulario web de captación de fondos, accesible desde el menú de acciones del módulo Campañas.


Formularios9.jpg


Paso 1

El envío de datos al CRM a través de este tipo de formularios provocará la creación de un compromiso de pago y su correspondiente primer pago. Tanto el compromiso de pago como el pago quedarán vinculados a la persona u organización que haya rellenado el formulario. El primer paso para la creación de un formulario de este tipo es precisamente decidir a qué módulo irán destinados los datos: Personas u Organizaciones.


Formularios10.jpg


Paso 2

El segundo paso consiste en la elección de los campos del módulo seleccionado en el paso anterior a incluir en el formulario creado. El funcionamiento de la pantalla está explicado en la sección Añadir o quitar campos al formulario.

Paso 3

En este paso definiremos los parámetros necesarios para el funcionamiento del formulario. A continuación se detalla el significado de cada parámetro:


Formularios11.jpg


  1. Cabecera: título que aparecerá en el formulario.
  2. Descripción: texto que aparecerá entre el título y los campos del formulario. Permite incluir una descripción del formulario o un texto de ayuda, por ejemplo.
  3. Etiqueta del botón Enviar: permite modificar la etiqueta de visualización del botón Enviar del formulario generado.
  4. URL de envío Post: es la dirección URL a la que se enviará la petición del formulario. El asistente para este tipo de formularios intentará detectar el tipo de conexión usado por SinergiaCRM en la instancia de la entidad (http o https) y adaptar la dirección a dicho tipo de conexión. Así pues, es posible que, a diferencia de otros formularios, no se deba modificar este valor, aunque sí es recomendable revisar que el tipo de conexión coincida con el detectado.
  5. Editar: permite editar la URL de envío Post por si hubiera que realizar algún cambio.
  6. URL de redirección: es la URL donde se redirigirá al usuario en caso de que la petición se haya realizado con éxito. Este campo es obligatorio ya que las pasarelas de pago requieren una dirección de reenvío tanto en caso de éxito como de error. Normalmente será una página del sitio web donde se encontraba el formulario.
  7. URL de redirección en caso de error: siguiendo la mismo lógica que el anterior punto, indica la URL de redirección en caso de que haya ocurrido algún error durante la gestión de la petición. Normalmente será una página del sitio web donde se encontraba el formulario.
  8. Tipo de pago que se generará: permite definir qué tipo de pago se generará con cada petición que llegue a través del formulario. Por ejemplo, podemos tener un formulario dedicado a captar pagos de tipo Donación y otro formulario dedicado a realizar altas de socios a los que se cobrará una Cuota. Los valores de este desplegable se adaptan a los valores indicados para el campo Tipo de pago del módulo Compromisos de pago.
  9. Tipo de relación a crear: opcionalmente se puede indicar un tipo de relación que se asignará de forma automática a la persona u organización que realice la donación. Si no se indica ningún valor no se creará ninguna relación.
  10. Plantilla de correo de notificación al usuario donante: opcionalmente se puede indicar una plantilla de correo para enviar una notificación al usuario conforme la operación se ha realizado (ver sección Notificación a la persona inscrita/donante mediante plantillas de correo). Si no se indica ninguna plantilla, no se le enviará ninguna notificación.
  11. Validar los números de identificación: Si se activa la opción (valor por defecto), el formulario validará que el dato introducido se ajuste al formato de un NIF/NIE español, salvo que el formulario incluya el campo Tipo de identificación con un valor que no sea NIF/NIE. Si se desactiva la opción, el número de identificación no se validará con independencia de si el campo Tipo está presente o no y tiene un valor u otro. Así pues, se recomienda que como práctica habitual se incluya la validación y que solo se omita en el caso de las entidades no españolas o para fomularios concretos en los que se considere necesario por alguna razón.
  12. Permitir pagos recurrentes con tarjeta/PayPal: Si se activa la opción, el formulario dará como válidas combinaciones entre el medio de pago indicado (tarjeta o PayPal) y cualquier periodicidad elegida. En caso contrario, solo se permitirán pagos puntuales. Cabe recordar que para la gestión de pagos recurrentes con tarjeta o PayPal es necesario haber contratado este servicio con la pasarela correspondiente.
  13. Campaña relacionada: todos los formularios de captación de fondos deben estar obligatoriamente vinculados a una campaña.
  14. Asignado a: permite indicar qué usuario de SinergiaCRM se hará cargo de la gestión del formulario (por defecto será el usuario activo). Este campo es especialmente importante ya que para cada petición que llegue desde el formulario, se enviará un correo electrónico a este usuario informando de los datos recibidos y el resultado de la operación (ver más información en Recepción en el CRM de los datos suministrados)).
  15. Pie del formulario: permite añadir un texto que aparecerá en la parte inferior del formulario.
  16. Número de ficheros adjuntos: permite incorporar al formulario campos de tipo upload (hasta un máximo de 5) para enviar archivos adjuntos al CRM.

Paso 5

Este paso permite editar la apariencia del formulario antes de su descarga. Para más información consultar la sección Formatear la apariencia del formulario. Cabe destacar que en el editor aparecerán también los campos necesarios del módulo de Compromisos de pago (Periodicidad, Medio de pago, etc.).

Paso 6

El último paso del formulario permite obtener el código HTML resultante. Para más información consultar la sección Pantalla de descarga del resultado del formulario.


Edición manual de formularios

Es posible modificar el funcionamiento original de los formularios a partir del código HTML obtenido mediante el asistente de generación de formularios. En Ejemplos de edición manual de formularios se recopilan algunos ejemplos de uso habitual.


Recepción en el CRM de los datos suministrados a través de formularios

Formularios básicos de campañas

Al recibirse los datos procedentes de un formulario vinculado a una campaña, el CRM creará un nuevo registro en Interesados o en Personas (dependiendo de la opción escogida al crear el formulario) con todos los datos suministrados.


Formularios de inscripción a eventos

En la recepción de datos para este tipo de formularios debemos distinguir dos casos:

1. Formularios creados antes de enero de 2017

Al recibirse una inscripción a un evento, el CRM tratará de localizar la dirección de correo electrónico suministrada a través del formulario en los módulos Personas, Organizaciones e Interesados (en este orden). Si la encuentra, se creará una inscripción al evento y se asociará a la persona, organización o interesado detectado. En caso contrario, se creará un nuevo interesado y se le vinculará la inscripción correspondiente.

Aunque es posible seguir recibiendo datos mediante estos formularios, se recomienda actualizar los formularios activos al nuevo formato, ya que incluye novedades importantes tanto en la creación como en el tratamiento de la información recibida.

2. Formularios creados a partir de enero de 2017

En la versión actual, un formulario de inscripción a eventos permite incluir datos de diferentes módulos: Personas, Organizaciones, Inscripciones y Compromisos de pago.

Se considera que la inscripción se realizará siempre para una persona en concreto, de la que estamos recogiendo los datos. Para tratar los datos de dicha persona se comprobará primero si se ha recibido un Número de identificación (NIF o similar). Si se ha recibido se buscarán registros coincidentes. Si no se encuentran o no se ha especificado un Número de identificación, se comprobará el campo Correo electrónico. Si se encuentra algún registro coincidente con alguno de los dos campos, se asignarán a ese registro el resto de registros implicados en la operación (la inscripción, el compromiso de pago si se requiere, etc.); de lo contrario se creará una nuevo registro en Personas y se le asignarán a éste los datos relacionados. Cabe tener en cuenta el caso especial en el que se reciban datos de una persona con un Número de identificación que no conste en el CRM y cuyo Correo electrónico coincida con el de una o más personas que ya están en el CRM y que tienen rellenado el campo Número de identificación. En este caso, aunque haya coincidencia de Correo electrónico se generará una nueva persona.

En caso de que el formulario incluya el sistema de pagos, el campo Número de identificación será obligatorio y si no se incluye se generará un error.

Si se ha incluido el módulo Organizaciones en el diseño del formulario, el programa buscará también registros preexistentes en el CRM. Si se ha incluido el CIF se buscará primero por dicho campo. En caso de no incluirse o no encontrar ningún registro coincidente, se buscará por el campo Nombre. De igual modo que para el módulo de Personas, si se encuentra una coincidencia por alguno de los campos, se vincularán a este los datos de la inscripción y otros que puedan generarse durante el proceso.

A partir de la actualización de junio de 2017, los formularios pueden incluir campos del módulo de Organizaciones de manera que sean opcionales para el usuario final. Así, si se indica que el campo Nombre de la Organización es opcional, el CRM únicamente procesará datos de la Organización si le llega dicho campo informado, de lo contrario no se procesará ningún dato relacionado con la Organización.

Al registro o registros creados o seleccionados se les vinculará un nuevo registro de inscripción, que contendrá los datos recibidos del formulario en caso de haber incluido campos de este módulo. Esta inscripción estará a su vez relacionada con el evento especificado en la creación del formulario.

Por último, si el formulario incluye el sistema de pagos se genera un nuevo compromiso de pago con los datos recibidos del formulario y se vinculará a la persona seleccionada. Como siempre que se crea un compromiso de pago, se genera automáticamente un primer pago asociado a la misma; a este pago se vinculará la inscripción generada. El tratamiento del compromiso de pago y del pago recién creados será igual que si se hubieran creado mediante un formulario de captación de fondos (ver apartado siguiente).

Para cada petición recibida a través de estos formularios se enviará al usuario del CRM asignado al formulario un correo electrónico en el que se indicarán:

  • Los datos enviados desde el formulario web (para cada módulo incluido)
  • Los datos de la inscripción creada.
  • Los datos de la persona a la que se ha asignado la inscripción.
  • Si se ha incluido el módulo Organizaciones, la organización a la que se ha asignado la inscripción.
  • La lista de los registros potencialmente duplicados en caso de haber detectado alguno (para Personas y Organizaciones).
  • En caso de haber incluido el sistema de pagos también se indicarán los datos del pago. Además, en este caso el asunto del correo empezará con un código numérico. Dicho código es útil especialmente en caso de pagos con tarjeta ya que, una vez finalizado el proceso de pago por pasarela de pago (TPV o PayPal) se envía un segundo correo al administrador informando del resultado de la operación, cuyo asunto empieza con el mismo código numérico.

Por último, si se había especificado una plantilla de correo de notificación al usuario, se aplicará dicha plantilla a los datos de los módulos implicados y se enviará un correo al usuario que ha realizado la inscripción.


Formularios de captación de fondos

Las peticiones de este tipo de formulario se procesan teniendo en cuenta el módulo de destino, el número de identificación recibido y el medio de pago.

1) Se comprueba el número de identificación recibido y se busca en el módulo de destino apropiado (Personas u Organizaciones) según lo indicado en el formulario:

- Si no existe ningún registro con ese número de identificación se genera uno nuevo en el módulo de destino. En el Estado de la campaña vinculada al formulario dicho registro aparecerá como un alta.

- Si sólo existe un registro con ese número de identificación, se selecciona el registro encontrado.

- Si existe más de un registro con ese número de identificación, se selecciona uno de ellos al azar.

2) Se genera un nuevo compromiso de pago con los datos recibidos del formulario y se vincula a la persona u organización seleccionada. Como siempre que se crea un compromiso de pago, se genera automáticamente un primer pago asociado a la misma:

- Si el medio de pago es Domiciliación, el pago generado se encontrará en estado No remesado y se deberá incluir en alguna remesa para hacerlo efectivo.

- Si el medio de pago es Tarjeta o PayPal, el pago se generará inicialmente en estado Pendiente y se redirigirá al usuario a la pasarela de pago correspondiente. Si la transacción se completa con éxito el pago pasará a estado Pagado. De no ser así, pasará a estado Rechazado TPV o quedará como Pendiente (ver #Control de pagos recibidos vía pasarelas online).

- Si el medio de pago es cualquier otro (Transferencia, etc.), el pago generado quedará en estado Pendiente hasta que se cambie manualmente en el propio CRM cuando proceda.

3) En caso de que en la pasarela (TPV o PayPal) se haya producido una autorización para permitir pagos recurrentes futuros, en el CRM sucederán algunos de los siguientes hechos:

- Si el medio de pago es tarjeta, se guardará en los campos Referencia para pagos recurrentes en TPV e Identificador de transacción COF del compromiso de pago la información necesaria para la gestión de pagos futuros (ver Remesas de pagos con tarjeta). Además se guardará también la Fecha de caducidad de la tarjeta en formato año-mes (AAMM). Esta fecha de caducidad es meramente informativa y no influye en la operativa del CRM. Queda a decisión de la entidad realizar la gestión que considere oportuna para lograr que el donante renueve la autorización para poder seguir emitiéndo cargos a su tarjeta.

- Si el medio de pago es tarjeta y la fecha de primer pago indicada en el formulario es futura no se efectuará el cobro del pago inicial hata la fecha indicada siempre que la autorización haya sido concedida.

- Si el medio de pago es PayPal se guardará en el campo Referencia para pagos recurrentes en PayPal del compromiso de pago la información necesaria para la gestión de pagos futuros. Cabe tener en cuenta que en el caso de PayPal no es necesaria ninguna actuación explícita desde el CRM para que los pagos futuros sean ejecutados: PayPal se encarga por completo de la gestión y comunica el resultado de cada operación al CRM, quien la registra oportunamente asignando el estado apropiado al pago implicado.

- PayPal no acepta fechas de primer pago futuras por lo que de recibirse una combinación de datos de este tipo el CRM modificará al vuelo la fecha de primer pago (estableciéndola al día en curso) antes de enviar la petición a PayPal.

- Tanto en tarjeta como en PayPal, si el proceso de autorización no finaliza correctamente el CRM rellenará la fecha de baja del compromiso de pago creado para evitar la futura creación de pagos recurrentes que no podrían ser cobrados.

Ni los datos de las tarjetas de crédito o débito ni ninguna credencial o dato identificativo de PayPal se almacenan en ningún caso en el CRM. Los datos que el CRM pueda registrar procedentes de las pasarelas de pago solo son interpretables por las propias pasarelas y no revelan ninguna información de los titulares de los medios de pago.

Para cada petición recibida a través de estos formularios se enviará al usuario del CRM asignado al formulario un correo electrónico en el que se indicarán:

  • Los datos enviados desde el formulario web.
  • Los datos del registro al que se ha asignado el compromiso de pago.
  • En caso de haber varios registros con el mismo NIF/NIE/CIF, la lista de los registros potencialmente duplicados.
  • En caso de haber sido necesario, los datos relativos al nuevo registro creado.
El sistema permite procesar información recibida a través de la versión anterior de los formularios de captación. Aún así, se recomienda actualizar los formularios activos a la versión actual (enero 2017). Lo explicado hasta este punto es aplicable a todas las versiones de los formularios de captación, a excepción del soporte a PayPal, añadido en las versiones posteriores a junio de 2017

Formularios creados a partir de enero de 2017

Además de lo ya explicado, cabe destacar algunos detalles que se han modificado en la versión más reciente:

  • En el correo de aviso al usuario del CRM asignado al formulario el asunto del correo empezará con un código numérico. Dicho código es útil especialmente en caso de pagos con tarjeta ya que una vez finalizado el proceso de pago por TPV se envía un segundo correo al usuario informando del resultado de la operación cuyo asunto empieza con el mismo código numérico.
  • Si en el momento de crear el formulario se especifica un tipo de relación al procesar el registro se creará una relación con organización o una relación con persona según corresponda y se le vinculará al registro de organización o persona seleccionado.
  • Si se había especificado una plantilla de correo de notificación al usuario, se aplicará dicha plantilla a los datos de los módulos implicados y se enviará un correo al usuario que ha realizado la donación.


Recepción de ficheros adjuntos

Los ficheros recibidos en el CRM a través de cualquier tipo de formulario web se guardarán en el módulo Documentos y quedarán relacionados con el interesado, la persona o la organización remitentes. De este modo, accediendo a la vista de detalla del interesado, persona u organización podrán verse en el subpanel de Documentos los ficheros recibidos. Adicionalmente, en el campo Descripción del módulo Documentos se indicará la procedencia del fichero (ejemplo: Fichero recibido desde un formulario web relacionado con el evento X / la campaña Y) para dotar de más contexto a los usuarios del CRM.

En caso de que la persona, interesado u organización ya formara parte del CRM y no se creara un nuevo registro con la recepción de la respuesta del formulario, los archivos adjuntos quedarían vinculados como documentos al registro ya existente.


Parámetros de configuración de la pasarela de pago

Las pasarelas de pago son aplicaciones web externas que cualquier sitio web (como por ejemplo el CRM) puede utilizar para solicitar el pago de transacciones económicas.

SinergiaCRM soporta dos pasarelas: el TPV de Redsys (el más habitual en España) y Paypal. En el caso del TPV de Redsys el CRM puede gestionar tanto los pagos tradicionales con tarjeta como los pagos con teléfono móvil vía Bizum. Cabe tener en cuenta que para procesar los pagos por Bizum mediante el TPV de Redsys suele ser necesario solicitar específicamente la habilitación del servicio a la entidad financiera que proporciona el TPV.

Tanto para el TPV de Redsys como para Paypal el CRM puede gestionar también la autorización para la emisión de pagos recurrentes futuros. Así como en el caso de Bizum, suele ser necesario solicitar específicamente la habilitación del servicio a la entidad financiera que proporciona el TPV o, en su caso, a PayPal.

Para la correcta comunicación entre el CRM y el TPV o Paypal existen una serie de parámetros accesibles desde el módulo Configuración que la entidad usuaria del CRM deberá cumplimentar. Cabe notar que algunos de las parámetros están desdoblados para trabajar en modo real o de pruebas.


TPV

  • TPV_CURRENCY: código de moneda a utilizar. Por defecto, 978 (Euro). Este parámetro no debería cambiar.
  • TPV_MERCHANT_CODE: código del comercio. Es un valor facilitado por la pasarela.
  • TPV_TERMINAL: terminal del comercio (un comercio puede tener varios terminales asociados). Es un valor facilitado por la pasarela, normalmente 1.
  • TPV_MERCHANT_NAME: nombre del comercio, es decir, de la entidad usuaria del CRM.
  • TPV_TEST: activa o desactiva el modo Test. Su valor por defecto es 1 (Test activado). Para pasar a realizar los pagos en modo real el valor de este parámetro debe ser modificado a 0 una vez realizadas las pruebas para comprobar que la pasarela está correctamente integrada con SinergiaCRM.
  • TPV_PASSWORD / TPV_PASSWORD_TEST: clave del comercio. Cadena de caracteres que se utiliza para cifrar la información enviada al TPV. Es un valor facilitado por la pasarela (diferente para los entornos de prueba y real del TPV).
Para que el TPV de Redsys devuelva correctamente al CRM la información de la transacción procesada es necesario asegurar que, en el área de administración del TPV en Redsys, el parámetro "Notificación ON-LINE" tenga como valor alguna de las opciones que incluyen "Con notificación Online (HTTP)", ya sea sólo HTTP, HTTP + Email comercio, etc. En caso de que no se incluya alguna de las opciones que contienen HTTP el TPV no devolverá la información de la transacción al CRM y en este quedarán los pagos en estado pendiente, en lugar de mostrarse como pagados o rechazados por el TPV, como sería deseable.


Trabajar con varios TPV

SinergiaCRM permite configurar más de un TPV, de modo que al preparar un formulario concreto la entidad puede decidir a través de qué TPV se van a realizar los pagos. Para disponer de un TPV adicional hay que hacer dos cosas:

1) Incorporar a la lista desplegable de medios de pago (stic_payments_methods_list) una opción cuyo valor interno empiece por card_ (la etiqueta visible puede ser cualquiera). Por ejemplo: card_futbol, card_campamentos, etc. Al generarse el formulario los medios de pago de este tipo se incorporarán al desplegable correspondiente junto a los habituales: tarjeta, paypal, domiciliación, etc. Posteriormente la entidad decidirá, como siempre, qué medios mantiene visibles para el usuario final, si reconvierte el campo desplegable en oculto con un valor fijo (ver #Convertir un campo en oculto), etc.

2) Duplicar los parámetros descritos en el apartado anterior usando el nombre TPV_ALT_XXXX_PARÁMETRO, donde XXXX debe ser el sufijo usado al definir el medio de pago del punto anterior. Así, siguiendo con el ejemplo anterior, para un medio de pago con valor interno card_futbol, los parámetros de configuración del TPV deberían ser del tipo TPV_ALT_FUTBOL_MERCHANT_CODE, TPV_ALT_FUTBOL_TERMINAL, etc. Solo es necesario duplicar aquellos parámetros cuyo valor varíe respecto del TPV por defecto. En caso de coincidencia no es necesario duplicar el parámetro y el CRM usará el valor del parámetro del TPV por defecto.


PayPal

  • PAYPAL_ID/ PAYPAL_ID_TEST: Usuario vendedor de PayPal de la entidad. Es un valor facilitado por PayPal (usualmente es el correo electrónico utilizado para loguearse en la cuenta de PayPal de la entidad). Para conseguir el valor de PAYPAL_ID_TEST, ver el siguiente apartado (Configuración adicional de la cuenta de PayPal).
  • PAYPAL_TEST: activa o desactiva el modoTest. Su valor por defecto es 1 (Test activado). Para pasar a realizar los pagos en modo real el valor de este parámetro debe ser modificado a 0 una vez realizadas las pruebas para comprobar que la pasarela está correctamente integrada con SinergiaCRM.


Configuración adicional de la cuenta de PayPal

Para poder hacer pruebas de pagos en PayPal es necesario crear unas cuentas de PayPal específicas para este fin, según el siguiente proceso:

1) Ir a la página web https://developer.paypal.com y loguearse con los datos de la cuenta de la entidad.

2) En el menú superior derecho de la pantalla, acceder a Dashboard y, a continuación, en la columna izquierda, a Sandbox / Accounts.

3) Si PayPal no las ha creado automáticamente, crear dos cuentas, una de negocio, para simular el vendedor, y otra personal, para simular un comprador. La primera será del tipo xxxxxx@business.example.com (este valor será el que tendrá que copiarse en el parámetro PAYPAL_ID_TEST). La segunda será del tipo xxxxxx@personal.example.com. Una vez creadas, clicando en ellas es posible editarlas y, por ejemplo, cambiar las contraseñas por defecto, si es de interés.

En el momento de hacer el pago por PayPal en un formulario en modo test, la pasarela pedirá un usuario y contraseña de test. En este punto usaremos el usuario y la contraseña de la cuenta de pruebas de comprador.


Control de pagos recibidos vía pasarelas online

Tal como se ha indicado en apartados precedentes, cuando se completa un pago en una pasarela virtual (TPV o PayPal), esta lo notifica al CRM, quien cambia el estado del pago a Pagado.

En caso de que el pago no llegue a formalizarse, pueden darse diferentes situaciones:

- TPV: si este notifica al CRM que el pago no ha sido completado, el CRM pondrá el pago en estado Rechazado TPV. Si el TPV no lo notifica, el pago quedará como Pendiente. Que la notificación se produzca dependerá, por ejemplo, de si el donante cancela explícitamente el pago en el TPV o, simplemente, cierra o abandona la página sin más. En este último caso el CRM no recibirá ninguna notificación procedente del TPV.

- PayPal: cualquier pago no completado quedará como Pendiente en el CRM porque PayPal no notifica estos casos.

Accidentalmente, también podría darse el caso de que un pago completado no fuera notificado por la pasarela al CRM o que este no estuviera puntualmente operativo en el momento del envío de la notificación. En estos poco probables casos un pago realizado seguiría marcado como Pendiente en el CRM.

En cualquier caso, y con independencia de la causa de que estén en ese estado, los pagos virtuales pendientes deberán ser tratados explícitamente por la entidad, ya sea para anularlos, borrarlos o marcarlos como pagados si se comprobara en la pasarela correspondiente que realmente llegaron a ser efectuados aunque el CRM no recibiera la confirmación.

Por otro lado, más allá de la existencia de pagos pendientes, la entidad puede querer llevar a cabo algún tipo de chequeo o comprobación entre los datos del CRM y los movimientos registrados en las pasarelas y/o en las cuentas bancarias.

En cualquiera de estos casos cabe tener en cuenta que tanto en el caso de TPV (parámetro Ds_Order) como en el de PayPal, el CRM utiliza el campo transaction_code del módulo de Pagos como identificador de la transacción y que es este valor, de tipo autonumérico, el que quedará registrado en los registros de las pasarelas o, eventualmente, en los ingresos bancarios. El campo transaction_code no suele aparecer por defecto en las vistas del módulo de Pagos, pero de ser necesario puede incorporarse como cualquier otro campo a las vistas que lo puedan precisar (básicamente las de detalle, lista o búsqueda, nunca en vistas editables).


Notificación a la persona inscrita/donante mediante plantillas de correo

Los formularios de inscripción a eventos y de captación de fondos permiten enviar correos de notificación a la persona que realiza la inscripción o la donación. Para ello se utiliza el mismo sistema de plantillas de correo que se usa en el envío de campañas y en otros procesos del CRM. Ver Plantillas de Email.

Para crear una nueva plantilla de correo se puede ir a Campañas / Campañas / Nueva plantilla de correo.

Tanto en el asunto del mensaje como en el cuerpo se pueden añadir campos de los módulos que se estén tratando en el momento de enviar la notificación. Para poder añadir los campos de diferentes módulos se ha extendido la funcionalidad de las plantillas, pero no ha sido posible modificar el interfaz de creación de las mismas, de modo que para añadir campos de módulos que no están el desplegable de Insertar variable será necesario escribir directamente el campo siguiendo el siguiente patrón:

$<nombre_interno_del_modulo>_<nombre_del_campo>
El nombre completo de la combinación módulo+campo debe estar escrito en minúsculas. De no ser así la plantilla no podrá ser procesada correctamente.

Por ejemplo, si queremos incluir el importe del pago deberíamos escribir stic_Payments_amount.

A continuación se muestra la lista de módulos disponibles para cada formulario y sus nombres internos. El nombre de los diferentes campos se puede consultar en Administración / Estudio en el propio CRM o en la página Estructura_de_datos:_módulos_y_campos de este wiki.

Formulario de inscripción a eventos
Nombre del módulo Nombre interno Inicio de la variable en la plantilla
Persona Contact $contact_<nombre_del_campo>
Organización Account $account_<nombre_del_campo>
Inscripción stic_Registrations $stic_Registrations_<nombre_del_campo>
Evento stic_Events $stic_Events_<nombre_del_campo>
Pago stic_Payments $stic_Payments_<nombre_del_campo>
Formulario de captación de fondos
Nombre del módulo Nombre interno Inicio de la variable en la plantilla
Persona Contact $contact_<nombre_del_campo>
Organización Account $account_<nombre_del_campo>
Pago stic_Payments $stic_Payments_<nombre_del_campo>

El CRM contiene dos plantillas (inscripción, captación) en los diferentes idiomas que pueden servir como ejemplo para diseñar la plantilla final a usar.


SPAM vía formularios

Es posible que en ocasiones los formularios web sean puerta de entrada de datos no deseados (SPAM) en el CRM. La experiencia indica que en los formularios de captación de fondos e inscripción a eventos esta situación es excepcional, mientras que es algo más probable en formularios básicos de campañas.


Incorporación de mecanismos de validación

Los formularios de SinergiaCRM no cuentan con un sistema tipo captcha propio que evite la recepción de datos no deseados, pero de ser necesario es posible añadir algún sistema de validación mediante javascript y HTML al formulario generado y, con ello, evitar la entrada en el CRM de datos no deseados. Los desarrolladores web suelen estar familiarizados con este tipo de técnicas.


Google reCAPTCHA

Entre las posibilidades que se pueden implementar, una de las más utilizadas es el sistema reCAPTCHA de Google. Para aplicarlo es necesaria una cuenta de Google y se requiere, además, un mínimo conocimiento técnico. En la guía para desarrolladores web de Google se describen los pasos a seguir para incluir reCAPTCHA (v3 o v2).

A continuación se sintetizan los pasos a seguir:

1. Hacer el registro del sitio web, habilitar el nuevo código y señalar el tipo de sistema de control que se quiere habilitar. Se podrá seleccionar reCAPTCHA v2 o v3 y es importante asegurar que el dominio informado coincida con el de la página web en la que está publicado el formulario (por ejemplo, sinergiacrm.org).


Configuracion reCAPTCHA.png


En este momento se creará el site key en la consola de administración de reCAPTCHA, que se usará posteriormente:


Claves reCAPTCHA.png


2. Incorporar las siguientes líneas al código HTML de los formularios generados en el CRM:

2.1. Esta línea puede ubicarse al principio o al final junto a las otras cláusulas <script> que ya se incluyen.

<script src="https://www.google.com/recaptcha/api.js" async="" defer=""></script>

2.2. Tras localizar el botón Envío del formulario' en el código:

<input class="button" name="Submit" type="submit" value="Enviar" />

deberá añadirse también la línea siguiente:

<div class="g-recaptcha" data-sitekey="indicar aquí el site key generado anteriormente"></div>

Este sistema puede suponer una primera barrera de protección ante mecanismos que usen directamente los formularios web para realizar los envíos no deseados. No obstante, este sistema no resultaría efectivo frente a mecanismos que operen directamente contra la dirección de entrada de los datos del formulario (URL post).


Limpieza de datos no deseados

En caso de que se detecte la presencia de registros no deseados en el CRM, es recomendable eliminarlos. Estos registros suelen presentar algún patrón que permite filtrarlos u ordenarlos para seleccionarlos y eliminarlos de forma masiva: direcciones de correo con terminaciones no habituales, fecha de creación concentrada en un período breve, etc.

Para facilitar el proceso de limpieza pueden aplicarse algunas de las acciones siguientes:

1) En Admin / Sistema / Configuración, ampliar el número de Elementos visibles por página en listas. De este modo será posible seleccionar y eliminar un mayor volumen de registros cada vez. Cabe tener en cuenta que mostrar un número elevado de registros por página comporta un mayor tiempo de carga y, por lo tanto, una vez se haya finalizado el proceso de limpieza, se recomienda volver a dejar el valor original de 20 registros por página.

2) Si no lo está, poner como visible el campo Fecha de creación en la vista de lista y usarlo para ordenar de forma descendente los registros mostrados. De esa forma, se verán en primer lugar aquellos registros más recientes y se podran eliminar más fácilmente los que se puedan haber creado desde la última limpieza realizada.

Mientras sigan apareciendo, se recomienda realizar la limpieza de registros no deseados de forma periódica, a fin de garantizar que la información registrada en el CRM es de calidad.


FAQS en torno al uso de formularios

En nuestro canal de Youtube tenéis a vuestra disposición un vídeo que agrupa algunas de las preguntas más frecuentes formuladas por parte de entidades usuarias de SinergiaCRM. Se recomienda ir al índice del mismo ya que contiene accesos directos a la resolución de cada una de ellas.

Cabe tener presente que la información más reciente es la que se refleja en el resto de apartados de este artículo. Algunos aspectos que aparecen en el vídeo podrían haber evolucionado con posterioridad a su edición.


Volver al índice