Difference between revisions of "Formularios"

From SinergiaCRM - Wikisuite
Jump to navigation Jump to search
 
(69 intermediate revisions by 6 users not shown)
Line 10: Line 10:
 
Actualmente existen tres tipos distintos de asistentes de creación de formularios en SinergiaCRM:
 
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 para registro de clientes potenciales.  
+
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.
 
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.
Line 43: Line 43:
 
====Campos obligatorios====
 
====Campos obligatorios====
  
En los formularios de '''Captación de fondos''' y de '''Inscripción a eventos''', al acceder a la pantalla de la imagen anterior, desde la que podemos añadir los campos de cada módulo que se agregarán al formulario, aquellos que sean obligatorios aparecerán directamente en la primera columna del formulario.
+
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.
 
 
Es importante tener en cuenta que los campos marcados con un asterisco son campos de obligada inclusión en el formulario. En caso de no incluir alguno de ellos aparecerá un mensaje de error informando de los campos que faltan por incluir.
 
  
 +
[[Archivo:Obligatorios.jpg|frame|center]]
  
[[Archivo:Obligatorios.jpg|frame|center]]
+
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.
  
  
Line 76: Line 75:
 
'''¿Cómo se accede?'''
 
'''¿Cómo se accede?'''
  
A través del asistente ''Crear formulario para registro de clientes potencias'', accesible desde el menú de acciones del módulo ''Campañas''.
+
A través del asistente ''Crear formulario web de Persona'', accesible desde el menú de acciones del módulo ''Campañas''.
 +
 
 +
[[Archivo:Formulario0.jpg|frame|center]]
  
 
'''Paso 1'''
 
'''Paso 1'''
Line 104: Line 105:
  
  
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 [[Formularios#Añadir_campos_upload_para_archivos_adjuntos_en_formularios_básicos_de_campañas|Añadir campos upload para archivos adjuntos en formularios básicos de campañas]].
+
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 [[Ejemplos_de_edición_manual_de_formularios#A.C3.B1adir_campos_upload_para_archivos_adjuntos_en_formularios_b.C3.A1sicos_de_campa.C3.B1as|Añadir campos upload para archivos adjuntos en formularios básicos de campañas]].
  
 
'''Paso 3'''
 
'''Paso 3'''
Line 113: Line 114:
  
 
El último paso del formulario permite obtener el código HTML resultante. Para más información consultar la sección [[Formularios#Pantalla_de_descarga_del_resultado_del_formulario|Pantalla de descarga del resultado del formulario]].
 
El último paso del formulario permite obtener el código HTML resultante. Para más información consultar la sección [[Formularios#Pantalla_de_descarga_del_resultado_del_formulario|Pantalla de descarga del resultado del formulario]].
 
  
 
===Formularios de inscripción a un evento===
 
===Formularios de inscripción a un evento===
Line 172: Line 172:
 
# '''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.  
 
# '''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.  
 
# '''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.  
 
# '''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.  
# '''Plantilla de correo de notificación al usuario''': 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 [[Formularios#Notificaci.C3.B3n_a_la_persona_inscrita.2Fdonante_mediante_plantillas_de_correo|Notificación a la persona inscrita/donante mediante plantillas de correo]]). Si no se indica ninguna plantilla no se le enviará ninguna notificación al usuario.  
+
# '''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 [[Formularios#Notificaci.C3.B3n_a_la_persona_inscrita.2Fdonante_mediante_plantillas_de_correo|Notificación a la persona inscrita/donante mediante plantillas de correo]]). Si no se indica ninguna plantilla no se le enviará ninguna notificación.  
 
# '''Evento relacionado''': todos los formularios de inscripción a eventos deben estar, lógicamente, vinculados a un evento.  
 
# '''Evento relacionado''': todos los formularios de inscripción a eventos deben estar, lógicamente, vinculados a un evento.  
 
# '''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 [[Formularios#Formularios_de_inscripción_a_eventos_2|Recepción de datos - Formulario de inscripción a eventos]]).  
 
# '''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 [[Formularios#Formularios_de_inscripción_a_eventos_2|Recepción de datos - Formulario de inscripción a eventos]]).  
Line 225: Line 225:
 
# '''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''.  
 
# '''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''.  
 
# '''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.  
 
# '''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.  
# '''Plantilla de correo de notificación al usuario''': 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 [[Formularios#Notificaci.C3.B3n_a_la_persona_inscrita.2Fdonante_mediante_plantillas_de_correo|Notificación a la persona inscrita/donante mediante plantillas de correo]]). Si no se indica ninguna plantilla, no se enviará ninguna notificación al usuario.  
+
# '''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 [[Formularios#Notificaci.C3.B3n_a_la_persona_inscrita.2Fdonante_mediante_plantillas_de_correo|Notificación a la persona inscrita/donante mediante plantillas de correo]]). Si no se indica ninguna plantilla, no se le enviará ninguna notificación.  
 
# '''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.
 
# '''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.
 +
# '''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.
 
# '''Campaña relacionada''': todos los formularios de captación de fondos deben estar obligatoriamente vinculados a una campaña.  
 
# '''Campaña relacionada''': todos los formularios de captación de fondos deben estar obligatoriamente vinculados a una campaña.  
 
# '''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 [[Formularios#Formularios_de_captación_de_fondos_2|Recepción en el CRM de los datos suministrados]])).  
 
# '''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 [[Formularios#Formularios_de_captación_de_fondos_2|Recepción en el CRM de los datos suministrados]])).  
Line 240: Line 241:
 
El último paso del formulario permite obtener el código HTML resultante. Para más información consultar la sección [[Formularios#Pantalla_de_descarga_del_resultado_del_formulario|Pantalla de descarga del resultado del formulario]].
 
El último paso del formulario permite obtener el código HTML resultante. Para más información consultar la sección [[Formularios#Pantalla_de_descarga_del_resultado_del_formulario|Pantalla de descarga del resultado del formulario]].
  
 +
== Edición manual de formularios ==
  
== Edición manual de los 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|Ejemplos de edición manual de formularios]] se recopilan algunos ejemplos de uso habitual.
 
 
A pesar de que el código HTML obtenido a través del asistente de generación de formularios es funcionalmente operativo (puede comprobarse fácilmente abriendo el fichero descargado en un navegador y cumplimentado el formulario), habitualmente se deseará modificar o ampliar su funcionamiento original.
 
 
 
Es importante tener presente que tanto la integración como la modificación del código HTML requerirán de un determinado nivel de conocimientos técnicos en tecnologías web como HTML, CSS o javascript. En este sentido, es importante hacer una valoración previa de lo que representará la integración y/o la modificación de cada formulario, a fin de saber si el equipo técnico de la entidad podrá hacerse cargo del proceso completo o si será necesario contar con la participación de los desarrolladores web.
 
 
 
<pre style="white-space: pre-wrap; color:green;">Como en cualquier otro aspecto del CRM, SinergiaTIC ofrece soporte a través del foro a los procesos de integración de formularios. Para que sea eficiente, es deseable que las personas que formulen las consultas sean aquellas que cuentan con los conocimientos técnicos requeridos y estén a cargo del proceso de integración/adaptación, sean internas o externas a la organización. Así pues, se recomienda que los desarrolladores web externos se den de alta en el foro y formulen las consultas directamente.</pre>
 
 
 
A continuación se presentan, sin ánimo de exhaustividad, algunos ejemplos habituales de posibles modificaciones a realizar en el código HTML del formulario. Cabe tener en cuenta que en tanto se respeten las denominaciones de los módulos y campos del CRM que aparecen en el código fuente del formulario y unas mínimas convenciones de sintaxis, cualquier modificación deseada puede ser aplicada.
 
 
 
 
 
=== Incluir campos adicionales ===
 
 
 
Una vez el formulario ya se ha descargado no queda almacenado en el CRM, por lo que no es posible editarlo ahí en caso de querer aplicar determinados cambios. O se vuelve a generar desde cero o se aplican los cambios manualmente sobre el código descargado. Un caso típico es la necesidad de incluir un campo omitido en el asistente o de un módulo del que el asistente no permite seleccionar campos (por ejemplo, el módulo ''Compromisos de pago'' en los formularios de captación de fondos).
 
 
 
A modo de ejemplo, el código siguiente permitiría incorporar al formulario el campo ''Descripción'' del módulo ''Compromisos de pago''.
 
<syntaxhighlight lang="html"><tr>
 
    <td id="td_lbl_stic_Payment_Commitments___description" style="text-align: left; font-size: 12px; font-weight: normal;" width="15%">
 
        <span>
 
            <label id="lbl_stic_Payment_Commitments___description" for="stic_Payment_Commitments___description">Descripción:</label> 
 
        </span>
 
    </td>
 
    <td id="td_stic_Payment_Commitments___description" style="font-size: 12px; font-weight: normal;" width="35%">
 
        <span id="sugarslot"> 
 
            <span id="sugarslot">
 
                <textarea id="stic_Payment_Commitments___description" type="text" name="stic_Payment_Commitments___description" /> </textarea>
 
            </span> 
 
        </span>
 
    </td>
 
</tr></syntaxhighlight>
 
 
 
Lo más relevante del código anterior es observar que para que el campo incluido sea reconocido por el CRM al recibir los datos, su atributo ''name'' tiene que estar formado por la concatenación del nombre interno del módulo en el CRM (en este caso, ''stic_Payment_Commitments''), tres guiones bajos ( ___ ) y el nombre interno del campo (''description''). Los nombres internos de módulos y campos pueden obtenerse fácilmente viendo el resto del código del mismo formulario o a través de ''Estudio'' (para más información sobre ''Estudio'', ver [[Adaptación_de_módulos_existentes|Adaptación de módulos existentes]]).
 
 
 
 
 
=== Hacer un campo obligatorio ===
 
 
 
Al generar un formulario en el CRM, este obliga al usuario a incluir en él todos los campos que sean obligatorios en el módulo base del formulario (''Personas'', ''Organizaciones'', ''Inscripciones'', ''Interesados'' y ''Público objetivo''). Estos campos también tendrán la condición de obligatorios en el formulario generado. En ocasiones, sin embargo, es necesario establecer como obligatorio en un formulario un campo que no lo es con carácter general en el CRM. Por ejemplo, campos típicos de contacto como ''Teléfono móvil'' o ''Correo electrónico'' no suelen ser obligatorios en el CRM pero sí suelen serlo en formularios web.
 
 
 
Para establecer como obligatorio un campo en un formulario bastaría con indicar de forma temporal en ''Estudio'' (ver [[Adaptación_de_módulos_existentes#Incorporación,_modificación_y_eliminación_de_campos|Adaptación de módulos]]) que el campo fuera requerido y una vez generado el formulario volver a desactivar la opción. Sin embargo, existen varias circunstancias en las que esta opción no es aplicable: cuando el formulario ya ha sido generado y no se desea volver a generar, cuando hay que aplicar la obligatoriedad sobre campos de determinados tipos (casillas de verificación o ''upload''), etc. En estos casos es posible editar el código del formulario para obtener el mismo efecto.
 
 
 
Para ello basta con buscar en el código HTML un ''input'' oculto (''hidden'') llamado ''req_id'' e incorporar a su ''value'' el nombre del campo deseado. Se pueden incorporar todos los campos necesarios, separándolos entre sí mediante punto y coma. El formulario validará que todos los campos indicados se hayan cumplimentado antes de permitir el envío de los datos al CRM.
 
 
 
En el ejemplo siguiente se muestra el código que hace obligatorios los campos ''Nombre'', ''Apellidos'' y ''Correo electrónico'' del módulo ''Personas''.
 
<syntaxhighlight lang="html"><input id="req_id" type="hidden" name="req_id" value="Contacts___first_name;Contacts___last_name;Contacts___email1;" /></syntaxhighlight>
 
 
 
Lo más relevante del código anterior es observar que el campo incluido tiene que estar formado por la concatenación del nombre interno del módulo en el CRM (en este caso, ''Contacts''), tres guiones bajos ( ___ ) y el nombre interno del campo (por ejemplo, ''first_name''). En cualquier caso, como el campo ya formará parte del formulario, podrá copiarse el valor desde el lugar donde se encuentre.
 
 
 
Como complemento a la acción anterior, y a efectos visuales, será necesario establecer la marca de campo obligatorio junto a la etiqueta del campo (por defecto es un asterisco rojo pero puede ser cualquier otro elemento adaptado a la imagen gráfica del sitio web). De no incluirse podría resultar confuso para el usuario pues el formulario seguirá exigiendo la cumplimentación del campo.
 
 
 
<syntaxhighlight lang="html"><span class="required" style="color: #ff0000;">*</span></syntaxhighlight>
 
 
 
Finamente, cabe mencionar que también es posible anular el requisito de obligatoriedad simplemente quitando el nombre del campo del punto indicado del código fuente.
 
 
 
 
 
=== Convertir un campo en oculto ===
 
 
 
Todos los campos que se seleccionan en el asistente del CRM y algunos más que el propio asistente incluye de forma automática son visibles por defecto en el formulario generado. Sin embargo, es posible que uno o más de estos campos, aunque sigan siendo necesarios a efectos de proceso, no deban ser accesibles para el usuario final. Por ejemplo, en un formulario de inscripción a eventos el importe de la inscripción puede ser un valor fijo y no un importe que el usuario pueda indicar libremente. O, también, en un formulario para recoger donativos para una campaña la periodicidad podría fijarse a ''Puntual'' o el medio de pago a ''Tarjeta''. A veces también se usa un campo oculto para poder saber desde qué formulario se están recibiendo los datos.
 
 
 
En estos casos basta con añadir o modificar un elemento ''input'' de tipo ''hidden'', estableciendo en el atributo ''value'' el valor deseado.
 
 
 
En el ejemplo siguiente se usa un campo oculto para indicar el valor del campo ''Medio de pago'' de una inscripción a un evento.
 
<syntaxhighlight lang="html"><input id="stic_Payment_Commitments___payment_method" type="hidden" name="stic_Payment_Commitments___payment_method" value="card" /></syntaxhighlight>
 
 
 
Lo más relevante del código anterior es observar que para que el campo incluido sea reconocido por el CRM al recibir los datos, su atributo ''name'' tiene que estar formado por la concatenación del nombre interno del módulo en el CRM (en este caso, ''stic_Payment_Commitments''), tres guiones bajos ( ___ ) y el nombre interno del campo (''payment_method''). Los nombres internos de módulos y campos pueden obtenerse fácilmente viendo el resto del código del mismo formulario o a través de ''Estudio'' (para más información sobre ''Estudio'', ver [[Adaptación_de_módulos_existentes|Adaptación de módulos existentes]]).
 
 
 
 
 
=== Establecer la fecha de primer pago ===
 
 
 
Cuando el envío de datos a través de un formulario supone la creación de un compromiso de pago en el CRM, la fecha de primer pago se establece por defecto a la del día en curso. Sin embargo, en algunas ocasiones puede ser interesante establecer una fecha de primer pago distinta de la actual. Por ejemplo, en el caso de entidades que gestionen cuotas de socio con periodicidad mensual puede considerarse oportuno empezar a cobrar la cuota el mes siguiente al del alta, particularmente cuando el alta se realiza en los últimos días del mes. Así pues, el campo podría introducirse como oculto en el formulario y el propio sitio web podría establecer su valor a conveniencia mediante javascript, de modo que resultara en algo como:
 
 
 
<syntaxhighlight>
 
<input id="stic_Payment_Commitments___first_payment_date" type="hidden" name="stic_Payment_Commitments___first_payment_date" value="2021-07-01" />
 
</syntaxhighlight>
 
 
 
 
 
=== Cambiar el usuario destinatario de las notificaciones ===
 
 
 
En el asistente de diseño se indica a qué usuario del CRM se asignará el formulario. Dicho usuario recibirá las notificaciones por correo electrónico que envía al CRM cuando cualquier persona cumplimenta el formulario. Para modificar este usuario hay que buscar la siguiente línea en el código fuente del formulario:
 
<syntaxhighlight lang="html"><input id="assigned_user_id" type="hidden" name="assigned_user_id" value="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"/></syntaxhighlight>
 
 
 
Las X representan el identificador interno (''id'') del usuario del CRM que recibe las notificaciones. Para que sea otro usuario quién las reciba basta localizar su ''id'' en el CRM y reemplazar el uno por el otro en el código fuente del formulario. El ''id'' puede obtenerse a través de un informe basado en el módulo de ''Usuarios'' o mirando el parámetro ''record'' en la URL de la vista de detalle del usuario en cuestión:
 
<syntaxhighlight>https://<entidad>.sinergiacrm.org/...&record=XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</syntaxhighlight>
 
 
 
 
 
=== Cambiar la campaña asociada ===
 
 
 
En los asistentes de creación de formularios básicos y de captación de fondos se indica la campaña a la que se asignará el formulario. Para modificar esta campaña hay que buscar la siguiente línea en el código fuente del formulario:
 
<syntaxhighlight lang="html"><input name="campaign_id" id="campaign_id" type="hidden" value="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" /></syntaxhighlight>
 
 
 
Las X representan el identificador interno (''id'') de la campaña del CRM asociada al formulario. Para asociar una campaña distinta basta localizar su ''id'' en el CRM y reemplazar el uno por el otro en el código fuente del formulario. El ''id'' puede obtenerse a través de un informe basado en el módulo de ''Campañas'' o mirando el parámetro record en la URL de la vista de detalle de la campaña en cuestión:
 
<syntaxhighlight>https://<entidad>.sinergiacrm.org/...&record=XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</syntaxhighlight>
 
 
 
 
 
=== Cambiar la plantilla de correo asociada ===
 
 
 
En los asistentes de creación de formularios de inscripción a eventos y de captación de fondos se puede indicar la plantilla de correo utilizada para confirmar la operación que se enviará a la persona que rellena el formulario. Para modificar esta plantilla hay que buscar la siguiente línea en el código fuente del formulario y sustituir el identificador que aparece tras la palabra ''email_template'' (hay que tener especial cuidado en respetar los caracteres especiales %3A, %22, etc.):
 
<syntaxhighlight lang="html"><input id="defParams" type="hidden" name="defParams" value="%7B%22version%22%3A%222%22%2C%22email_template_id%22%3A%22XXXXXX-XXXX-XXXX-XXXX-XXXXXXXX%22%2C%22relation_type%22%3A%22%22%7D" /></syntaxhighlight>
 
 
 
Las X representan el identificador interno (''id'') de la plantilla del CRM asociada al formulario. Para asociar una plantilla distinta basta localizar su ''id'' en el CRM y reemplazar el uno por el otro en el código fuente del formulario. El ''id'' puede obtenerse mirando el parámetro ''record'' en la URL de la vista de detalle de la plantilla en cuestión:
 
<syntaxhighlight>https://<entidad>.sinergiacrm.org/...&record=XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</syntaxhighlight>
 
 
 
 
 
=== Cambiar el evento asociado ===
 
 
 
En el asistente de creación de formulario de inscripción a un evento se indica el evento al cual se asignará el formulario. Para modificar el evento hay que buscar la siguiente línea en el código fuente del formulario:
 
 
 
<syntaxhighlight lang="html"><input id="event_id" type="hidden" name="event_id" value="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" /></syntaxhighlight>
 
 
 
Las X representan el identificador interno (''id'') del evento del CRM asociado al formulario. Para asociar un evento distinto basta localizar su ''id'' en el CRM y reemplazar el uno por el otro en el código fuente del formulario. Para saber como obtener el "ID" consultar [https://wikisuite.sinergiacrm.org/index.php?title=Estructura_de_datos:_m%C3%B3dulos_y_campos#Notas_acerca_de_los_ID_de_registros| Notas acerca de los ID de registros].
 
 
 
  
=== Modificar las URLs de redirección ===
 
 
En cada uno de los formularios se deben definir una "URL de redirección" y en algunos casos también una "URL de redirección en caso de error". Es posible modificar estas direcciones de redirección desde el código fuente del formulario.
 
 
Para modificar la "URL de redirección" hay que buscar la siguiente línea en el código fuente del formulario y modificar la URL:
 
 
<syntaxhighlight lang="html"><input id="redirect_url" type="hidden" name="redirect_url" value="https://www.urlredireccion.org/gracias" /></syntaxhighlight>
 
 
 
Para modificar la "URL de redirección en caso de error" hay que buscar la siguiente línea en el código fuente del formulario y modificar la URL:
 
 
<syntaxhighlight lang="html"><input id="redirect_ko_url" type="hidden" name="redirect_ko_url" value="https://www.urlredireccion.org/error" /></syntaxhighlight>
 
 
 
Los valores a modificar se encuentran después de ''value='' y se debe introducir la URL entre comillas.
 
 
 
=== Modificar el importe de las inscripciones ===
 
 
En el asistente de creación de formulario de inscripción a un evento que incluya el sistema de pago se puede indicar el importe que deberá pagar la persona que se inscriba. Si se desea modificar este valor una vez creado el formulario, se deberá buscar la siguiente línea en el código fuente del formulario:
 
 
<syntaxhighlight lang="html"><input id="stic_Registrations___amount_dec_c" type="hidden" name="stic_Registrations___amount_dec_c" value="15,3" /></syntaxhighlight>
 
 
El valor a modificar se encuentra detrás de "value=", donde se podrá entrar el importe deseado entre las comillas.
 
 
 
=== Añadir campos upload para archivos adjuntos en formularios básicos de campañas ===
 
 
En el asistente de generación de formularios básicos de campañas no es posible indicar la inclusión de campos de tipo upload para subir ficheros al CRM vía formularios web. En caso de que se desee contar con esta posibilidad hay que editar el código fuente del formulario de la siguiente manera:
 
 
1) Localizar la etiqueta <''form>'' y añadirle el atributo ''enctype="multipart/form-data"'' de modo que esta línea:
 
<syntaxhighlight lang="html"><form id="WebToLeadForm" action="http://entidad.sinergiacrm.org/index.php?entryPoint=WebToLeadCapture" method="POST" name="WebToLeadForm"></syntaxhighlight>
 
 
se convierta en esta:
 
<syntaxhighlight lang="html"><form id="WebToLeadForm" action="http://entidad.sinergiacrm.org/index.php?entryPoint=WebToLeadCapture" method="POST" name="WebToLeadForm" enctype="multipart/form-data"></syntaxhighlight>
 
 
2) Añadir el siguiente código en el lugar deseado entre los campos del formulario:
 
<syntaxhighlight lang="html"><div class="row">
 
    <div class="col">
 
        <label>Fichero adjunto 1:</label>
 
        <input name="documents[]" id="Documents___document1" type="file"/>
 
    </div>
 
    <div class="col"> </div>
 
    <div class="clear"> </div>
 
</div></syntaxhighlight>
 
 
El código anterior introduce una capa con dos columnas, que es la estructura que por defecto genera el asistente del CRM. Si el formulario ha sido modificado para disponer los campos de otra forma, el código anterior deberá adaptarse para que encaje con la nueva disposición. Lo relevante, como en otros casos, es conservar los nombres e identificadores de los campos (atributos ''name'' e ''id'').
 
 
Para añadir más de un control de tipo ''upload'' basta con replicar el código de las dos primeras celdas en cualquier otro par de celdas de la misma fila o de una fila nueva sustituyendo el id ''Documents___document1'' por ''Documents___document2'' y sucesivos. En realidad no es imprescindible que los ''id'' tengan esta denominación, basta con que no se repitan entre sí ni con cualquier otro id del formulario. Lo que sí debe garantizarse es que el array que los reúne y los manda al servidor mantenga el nombre ''documents[]''.
 
 
3) Por último, debe añadirse un campo oculto que indique al CRM en qué idioma debe escribir los comentarios sobre el origen de los ficheros recibidos (ver el apartado [[Formularios#Recepción_de_ficheros_adjuntos|Recepción de ficheros adjuntos]]). En caso de no indicar esta opción los comentarios se escribirán en el idioma del navegador desde el que se envía el formulario.
 
<syntaxhighlight lang="html"><input id="language" type="hidden" name="language" value="ca_ES" /></syntaxhighlight>
 
 
=== Evitar envíos múltiples de formulario al hacer click rápidamente ===
 
 
En los formularios creados con el CRM antes de 04/01/2022 se produce un error que consiste en el envío del formulario tantas veces como se hace click en el botón enviar, y el guardado de los datos tantas veces como se hace click, lo que puede provocar la existencia de datos repetidos e inconsistentes. En los formularios creados a partir de la fecha indicada este comportamiento ha sido corregido.
 
 
En caso de querer aplicar el parche que soluciona el problema proceder del siguiente modo:
 
 
==== En el caso de Formularios de registro de Personas o Interesados
 
 
Añadir justo al principio del bloque de código Javascript del formulario el siguiente código
 
<syntaxhighlight lang="javascript">
 
<script type='text/javascript'>
 
    // Código añadido ######################################
 
    var formHasAlreadyBeenSent = false;
 
   
 
    /**
 
    * Prevent multiple form submissions
 
    *
 
    * @return void
 
    */
 
    function lockMultipleSubmissions() {
 
        if (formHasAlreadyBeenSent) {
 
            console.log("Form is locked because it has already been sent.");
 
            event.preventDefault();
 
        }
 
        formHasAlreadyBeenSent = true;
 
    }
 
   
 
    // Attach function to event
 
    document.getElementById("WebToLeadForm").addEventListener("submit", lockMultipleSubmissions);
 
 
 
    // Fin código añadido ######################################
 
 
</syntaxhighlight>
 
  
 
== Recepción en el CRM de los datos suministrados a través de formularios ==
 
== Recepción en el CRM de los datos suministrados a través de formularios ==
Line 443: Line 250:
 
=== Formularios básicos de campañas ===
 
=== 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'' con todos los datos suministrados.
+
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.
  
  
Line 469: Line 276:
 
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.
 
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.
+
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).
 
 
Existen algunas diferencias en función del medio de pago seleccionado:
 
 
 
*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 del TPV o de PayPal, según corresponda. Si la transacción se completa con éxito el pago pasará a estado ''Pagado''; de lo contrario pasará a estado ''Rechazado TPV''.
 
*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.
 
<pre style="white-space: pre-wrap; color:green;">Los datos de las tarjetas de crédito o débito ni ninguna credencial o dato identificativo de PayPal no se almacenan en ningún caso en el CRM.</pre>
 
  
 
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:
 
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:
Line 492: Line 292:
 
=== Formularios de captación de fondos ===
 
=== Formularios de captación de fondos ===
  
Las peticiones de este tipo de formulario se procesan teniendo en cuenta el módulo de destino, el NIF recibido y el medio de pago:
+
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.
  
#Se comprueba el ''NIF/NIE/CIF'' recibido y se busca en el módulo destino apropiado: ''Personas'' u ''Organizaciones'' (no en los dos a la vez).
+
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 ''NIF/NIE/CIF'', se genera uno nuevo en el módulo de destino indicado. En el ''Estado'' de la campaña vinculada al formulario dicho registro aparecerá como un alta.  
+
 
##Si sólo existe un registro con ese ''NIF/NIE/CIF'', se selecciona el registro encontrado.  
+
- 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 existe más de un registro con ese ''NIF/NIE/CIF'', se selecciona uno de ellos al azar.   
+
#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 sólo existe un registro con ese número de identificación, se selecciona el registro encontrado.
##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 del TPV o PayPal, según proceda. Si la transacción se completa con éxito el pago pasará a estado ''Pagado''; de lo contrario pasará a estado ''Rechazado TPV''.  
+
- Si existe más de un registro con ese número de identificación, se selecciona uno de ellos al azar.   
##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.  
+
 
<pre style="white-space: pre-wrap; color:green;">Los datos de las tarjetas de crédito o débito ni ninguna credencial o dato identificativo de PayPal no se almacenan en ningún caso en el CRM.</pre>
+
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 [[Compromisos_de_pago,_Pagos_y_Remesas#Remesas_de_pagos_con_tarjeta|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.
 +
 
 +
<pre style="white-space: pre-wrap; color:green;">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.</pre>
  
 
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:
 
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:
Line 528: Line 348:
  
  
==Parámetros de configuración de la pasarela de pago para formularios de captación de fondos==
+
== 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.  
 
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óbil 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.
+
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.
 
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.
Line 553: Line 375:
 
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:
 
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_payment_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.
+
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.
 
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 ===
 +
 
 +
* '''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.C3.B3n_adicional_de_la_cuenta_de_Paypal|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.
  
* '''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.C3.B3n_adicional_de_la_cuenta_de_Paypal|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 ==
  
== 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:
  
Para poder integrar la cuenta de Paypal de la entidad con los formularios y el CRM es necesaria una configuración adicional:
+
1) Ir a la página web [http://developer.paypal.com https://developer.paypal.com] y loguearse con los datos de la cuenta de la entidad.
  
'''Activar la Notificación de Pago Instantánea (IPN):'''
+
2) En el menú superior derecho de la pantalla, acceder a ''Dashboard'' y, a continuación, en la columna izquierda, a ''Sandbox / Accounts''.
  
Para activar la IPN, hay que realizar los siguentes pasos:
+
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.
  
# Entrar en la cuenta de Paypal que se va a usar para recibir los fondos y acceder a ''Perfil / Configuración de la Cuenta''.  
+
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.
# Acceder a ''Perfil de la empresa / Notificaciones / Notificaciones de pago instantáneas - Actualizar''.
 
# Pulsar en ''Seleccionar configuración de IPN''.
 
# Rellenar la ''URL de notificación'' con el siguiente valor: ''https://<nombre de="" la="" entidad="">.sinergiacrm.org/index.php?entryPoint=STIC_WebForm_paypal_response</nombre>'' y marcar la opción ''Recibir mensajes de IPN (Activado)''.
 
# Pulsar en ''Guardar''.  
 
  
'''Pruebas en modo test'''
 
  
Para poder hacer pruebas de pagos en Paypal es necesario crear las cuentas TEST de Paypal mediante los siguientes pasos:
+
== Control de pagos recibidos vía pasarelas online ==
  
# Ir a la página web [http://developer.paypal.com https://developer.paypal.com] y loguearse con los datos de la cuenta de la entidad.
+
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 el menú superior derecho de la pantalla, acceder a ''Dashboard'' y, a continuación, en la columna izquierda, a ''Sandbox / Accounts''.
 
# 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.
+
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).
  
  
Line 657: Line 486:
  
  
== Control de pagos recibidos vía pasarelas online ==
+
== 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'' 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.
 +
 
 +
 
 +
=== 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 [https://www.youtube.com/c/SinergiaCRM canal de Youtube] tenéis a vuestra disposición un [https://youtu.be/FqVuHfZwIoc 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.
 +
 
 +
<youtube width="500" height="360">https://youtu.be/FqVuHfZwIoc</youtube>
  
En apartados anteriores ya se ha descrito el flujo de cambios de estado de los pagos procesados vía pasarela electrónica (TPV o Paypal) hasta llegar a la condición de pagados o rechazados por la pasarela correspondiente. De todos modos, la entidad usuaria del CRM 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 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).
+
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.  
  
  
 
[[Manual_de_SinergiaCRM|Volver al índice]]
 
[[Manual_de_SinergiaCRM|Volver al índice]]

Latest revision as of 07:48, 19 May 2022

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 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.


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