Migración de datos

From SinergiaCRM - Wikisuite
Revision as of 16:36, 18 May 2022 by Jaume.Albaiges (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Introducción

El CRM está formado por varios módulos, cada uno de los cuales aloja información relacionada con un tema determinado (personas, organizaciones, proyectos, etc.). Cada módulo dispone de una ficha (llamada formalmente Vista de detalle) en la que se muestran los datos (los campos) que describen un elemento concreto (un registro) del módulo en cuestión.

Por otra parte los módulos pueden estar relacionados entre sí, de modo que la información asociada a un determinado elemento de un módulo va mucho más allá de su información directa, contenida en el propio módulo. En la ficha a la que se ha hecho mención en el párrafo anterior, esta información relativa a los módulos asociados se visualiza en los subpaneles que aparecen después de los datos propios del módulo.

Conocer la estructura de módulos y relaciones del CRM es fundamental para realizar una migración de datos correcta, es decir, para ubicar cada dato en el módulo adecuado y, a su vez, relacionarlo apropiadamente con datos de otros módulos.

Antes de describir con detalle y paso a paso el trabajo a realizar, comentaremos cualitativamente un ejemplo habitual.

Supongamos que tenemos dos listas con personas que han participado en dos eventos distintos que en algún momento del pasado ha organizado la entidad. Cada lista tiene una estructura similar donde consta el nombre de la persona, su correo electrónico y su teléfono móvil.

De estas listas se desprende información relativa a las Personas (nombre, teléfono, correo), a los Eventos (nombre del evento, fecha en que se ha realizado) y a la participación de las personas en los eventos, concepto que en el CRM denominamos como Inscripciones (puede ser que haya personas que hayan participado en uno, en el otro o en ambos).

Con las dos listas se deberá hacer un proceso como el siguiente:

- Unirlas en un solo listado haciendo coincidir por columnas los campos equivalentes.

- Ordenar el listado resultante por las columnas que permitan encontrar personas duplicadas (nombre, correo, teléfono).

- Combinar los datos de los duplicados detectados de manera que quede una persona lo más completa posible (ya que para una misma persona en un listado podría aparecer el teléfono y en el otro, el correo).

- Marcar en cada fila o registro en cuáles de los dos eventos ha participado una persona.

- Importar los datos correspondientes a las personas.

- Importar los datos correspondientes a los eventos (en este caso, como se trata sólo de dos, se podrían introducir directamente en el CRM manualmente sin necesidad de realizar el proceso de importación).

- Importar los datos correspondientes a participación de las personas en las eventos, es decir, las inscripciones.

En los apartados siguientes se analizará este proceso con más detalle.

En nuestro canal de Youtube tenéis a vuestra disposición un vídeo en torno al proceso de Migración de datos



Análisis de fuentes

La migración al nuevo sistema CRM de los datos que históricamente pueda haber acumulado una entidad es una de las partes más complejas y pesadas del proceso de implantación de la herramienta.

En este sentido, antes de determinar el alcance funcional que deberá ofrecer el CRM a una entidad concreta, conviene hacer una exhaustiva recopilación de todas las fuentes de datos existentes que se querrán integrar. Quien más, quien menos, toda persona y todo departamento de cualquier organización acaba teniendo sus "listas" (hojas de cálculo, agendas los programas de correo electrónico, etc.). Aparte de eso, pueden existir también "aplicaciones corporativas" (bases de datos, etc.). Todos estos depósitos deben ser debidamente analizados e inventariados.

El análisis implicará determinar qué datos actualmente disponibles deberán ser incorporados al CRM y cuáles podrán ser obviados. A lo largo de su vida una entidad acumula información que en un determinado momento se ha considerado relevante pero que posteriormente no ha tenido utilidad. El proceso de migración al CRM es un buen momento para deshacerse de ella.

De la información que sea necesario traspasar al CRM, habrá que decidir, lista por lista, a qué módulo y campo del CRM irá a parar cada columna disponible. De alguna manera, hay que establecer correspondencias entre la estructura (o estructuras) actual de información y la del CRM. Todo ello permitirá saber qué módulos del CRM deberán usarse y si habrá que crear otros nuevos o adaptar en cierta medida los existentes.


Análisis de indicadores

Nos parece importante en este punto hacer un recordatorio de otra cuestión que debería realizarse en paralelo a la labor de recopilación interna de fuentes de datos. A menudo, al poner en marcha la herramienta las entidades se centran en la recopilación de los datos que están dispersos por la entidad y en cómo estructurar los mismos en los distintos módulos del CRM. No obstante, se debería esbozar también, mínimamente, qué información se necesitará en el trabajo habitual tras la implantación, en clave de presente y de futuro de la entidad. Buena parte de esta información se obtendrá, una vez puesto en marcha el CRM, mediante la agrupación/visualización de datos a través de informes que facilitarán la valoración del trabajo cuantitativo y cualitativo que lleva a cabo la entidad.

En este proceso es interesante que participen tanto personas técnicas de la entidad como personas responsables (niveles de dirección / gerencia de la organización) para que se tengan en cuenta simultáneamente las necesidades operativas y las estratégicas en el uso que se hará del CRM.

Por citar algunos ejemplos, sería bueno plantearse preguntas del tipo: ¿Qué información es necesaria en la elaboración de memorias internas y de presentación externa de la entidad? ¿Con qué periodicidad y con qué nivel de detalle se requiere? ¿Qué se necesita en las reuniones de reporte internas y de órganos de gobierno para la toma de decisiones? ¿Qué se requiere en el desarrollo de las actividades y programas de acción directa que se llevan a cabo cada día? ¿Se podría extraer información que sirva en el desarrollo de la labor de incidencia política o de representación institucional de la entidad? ¿Qué datos son relevantes en relación a las campañas que se prevé poner en marcha?

Se recomienda este ejercicio en este punto porque la estructuración de los datos facilitará los procesos posteriores de extracción de información y en función de cómo se organicen los diferentes módulos de datos será más o menos sencillo e inmediato el tratamiento de la información. Garantizar que sea fácil obtener indicadores que se necesitarán habitualmente sería uno de los objetivos de este proceso de definición previo a la migración de datos.


Traspaso de datos de las fuentes originales en hojas de cálculo

Tal y como ya se ha indicado, el CRM consta de una serie de módulos, cada uno de los cuales almacena información de una determinada tipología (organizaciones, personas, proyectos, actividades, etc.).

La importación de datos en el CRM se realiza módulo a módulo. Inicialmente, los datos se extraen de sus ubicaciones originales y se depositan en hojas de cálculo que luego son fácilmente importables sobre el CRM. A partir de las fuentes recopiladas habrá que generar una o más de estas hojas de cálculo para cada módulo de destino. Veamos un ejemplo.

Supongamos que la entidad tiene una base de datos de empresas con las que ha mantenido relación y por otro lado tiene una lista de escuelas en las que ha hecho actividades. Ambas listas, tanto la de empresas como la de escuelas, irán a parar al mismo módulo del CRM, el de Organizaciones. Como es de esperar que ambas listas tengan intersección nula (difícilmente una escuela aparecerá también en la lista de empresas y viceversa), cada conjunto de datos se puede depositar en una hoja de cálculo independiente y después importar por separado. Por el contrario, si entre dos listados hay una intersección relevante (por ejemplo, un listado de escuelas públicas de Cataluña y un listado de escuelas de todo tipo de la provincia de Barcelona), convendrá fusionar ambos listados en una sola hoja de cálculo para facilitar la detección, combinación y eliminación de duplicados antes de la importación, tal y como se explicará en un apartado posterior.

Como paso final de este proceso inicial de traspaso de datos de sus fuentes originales a las hojas de cálculo se realizará una copia de seguridad de los archivos generados, de manera que si en las actuaciones posteriores de limpieza, homogeneización y demás se produce alguna incidencia, siempre sea posible rehacer el proceso o comparar datos con facilidad.


Selección de los campos y los registros

Una vez todos los datos de un determinado módulo ya están todos juntos en un mismo archivo, procedemos a la eliminación de las columnas que no queremos importar al módulo en el que estamos trabajando (campos que han dejado de tener interés, que se gestionarán de una manera diferente, que son redundantes con otros, etc.).

Este proceso, sencillo en el caso de los campos, se puede aplicar también a nivel de registros. En este caso no es tan evidente ni rápido, pero eliminar información que no es útil ni a efectos de memoria histórica hará más valioso el resultado final. Por ejemplo, imaginemos que en un archivo de organizaciones aparece un conjunto de empresas procedente de un listado que hace años apareció de no se sabe muy bien dónde y con el que nunca se ha hecho ninguna acción de ningún tipo. Si además sospechamos que la calidad, la completitud o la vigencia de los datos hace que este conjunto de registros sea de poco valor, quizás mejor no incorporarlos al CRM y, por tanto, eliminarlos del listado de importación.


Formato de los campos a importar

Algunos tipos de campos pueden presentar particularidades que conviene tener en cuenta. Entre otros:

- Booleanos (verdadero/falso). Se utiliza 1 para valores de tipo cierto (o ) y 0 para los de tipo falso (o no).

- Correos electrónicos. Cuando en una misma casilla encontramos más de una dirección de correo, conviene separarlas en varias columnas. Igualmente, hay que comprobar que tienen una estructura válida. Tanto si en una casilla hay más de una dirección como si sólo hay una pero no es válida (por ejemplo, no contiene el símbolo @ o incumple cualquier otra de las normas de construcción de direcciones de correo) el CRM no importará el registro en cuestión.

- Códigos postales (y otros campos de texto con casuística similar). Conviene tener cuidado con los que empiezan por 0, ya que es fácil que en algunos casos este 0 inicial desaparezca al manipular el campo en una hoja de cálculo. En este sentido, suele ser útil dar formato explícito de texto a las celdas que deberán contener códigos postales o datos similares (números de teléfono, cuentas bancarias, etc.).

- Teléfonos. De entrada mejor eliminar espacios, puntos, guiones, comas, etc. particularmente en teléfonos estándares (9 dígitos). Cuando se trata de teléfonos con extensiones, del extranjero, etc. determinar un formato y mantenerlo.

- Campos multivalor. Cuando un campo puede tomar varios valores de entre un conjunto pre-establecido (por ejemplo, idiomas que una persona habla, donde una misma persona puede hablar Español, Inglés, Catalán, etc.), estos valores se dispondrán separados por comas en una misma casilla.

- Fecha. Conviene conocer el formato que sigue un campo de este tipo (día/mes/año, mes/día/año, etc.). Si no coincide con el formato propio del CRM, la importación dará error.


Normalización y compleción de datos

El paso de la normalización es uno de los más importantes del proceso de migración. Se entiende por normalizar garantizar que los valores de un determinado campo siguen una misma estructura y se representan siempre de la misma manera (mayúsculas, minúsculas, acentos, etc.).

Para normalizar una tabla de datos hay que ordenarla sucesivamente por las diferentes columnas normalizables. De esta manera resulta sencillo encontrar valores similares pero no iguales y corregirlos. También puede ser de ayuda utilizar la funcionalidad de filtrado que suelen ofrecer las aplicaciones de hoja de cálculo.

Igualmente, se puede aprovechar este proceso para completar masivamente campos vacíos. A modo de ejemplo, si se ordena una tabla por la columna de Población y se encuentra un conjunto de registros de la ciudad de Barcelona que no tienen provincia asociada, resulta muy sencillo asignarla a todos ellos de una sola vez.

Para ganar en eficiencia en las tareas indicadas en los dos apartados anteriores, se recomienda consultar el artículo Fórmulas de utilidad en las hojas de cálculo.


Eliminación o fusión de duplicados

Aunque el CRM tiene la capacidad de detectar duplicados entre la información ya importada en base a determinados campos clave (nombre, correo electrónico, etc.), es siempre recomendable realizar un primer proceso de depuración de posibles registros duplicados antes de la carga de los datos al sistema.

El método para hacerlo es ordenar por varias columnas (nombre de la entidad, nombre persona, mail, teléfono, web, etc.) y establecer fórmulas para detectar cuándo un valor y el de la fila siguientes son iguales, para que su localización sea sencilla.


Importación de datos

Cada módulo del CRM dispone de una función para importar datos externos sin tener que introducirlos manualmente. En los apartados siguientes se describe el proceso paso a paso.


1) Subir al servidor el archivo con los datos a importar

Antes de poder migrar los datos se deben crear en el módulo de destino aquellos campos que el CRM no ofrece por defecto y que se han considerado necesarios por parte de la entidad (ver Incorporación, modificación y eliminación de campos). Si el módulo entero es nuevo, también habrá que haberlo creado (ver Creación de módulos nuevos).

El archivo de datos a importar debe tener formato CSV (Comma Separated Value, valores separados por comas). Cualquier aplicación de hoja de cálculo puede hacer esta operación de forma sencilla a través de las habituales funciones del tipo Guardar como....

El CRM permite descargar una plantilla de importación de archivos con las cabeceras apropiadas para facilitar el posterior mapeo de campos entre el fichero y el CRM así como unos datos de ejemplo. Esta plantilla contiene todos los campos del módulo aunque posiblemente solo una parte de ellos sea necesaria en la importación a realizar. En cualquier caso, no es obligatorio usarla.

El archivo de importación no puede contener dos columnas con el mismo nombre y el nombre del archivo no puede contener espacios (de todos modos, se recomienda que el nombre del archivo no contenga ningún caracter especial).


29.jpg


Aunque el sistema permite tanto publicar registros nuevos como actualizar registros existentes, en este caso haremos referencia sólo al primer proceso.


2) Indicar, si es necesario, las características globales de los datos subidos

En este paso el CRM presenta una muestra de los dos primeros registros leídos del archivo subido, por lo que se puede comprobar que la primera carga se ha hecho bien. A través del botón Mostrar opciones avanzadas podemos fijar las opciones de migración que el CRM debe tener en cuenta: formatos de fecha y hora, de números, de moneda, etc.


30.jpg


Particularmente importante es determinar la [codificación] del archivo subido. Dicho sencillamente, la codificación es el mecanismo por el que las aplicaciones informáticas representan internamente los diferentes caracteres que contiene un texto. Si la codificación indicada en el proceso no coincide con la real (la de la hoja de cálculo que se importará), los caracteres especiales no se mostrarán correctamente en el CRM una vez terminada la importación. Las codificaciones más habituales son ISO-8859-1 y UTF-8 y el error más habitual es tomar una por la otra.

Cuando la codificación no está bien seleccionada, es habitual observar algunas disfunciones en los datos de muestra que aparecen en pantalla. A modo de ejemplo, en vez de leer un texto como este: Ángeles Suriñach, se leería uno como este: Àngeles Suriñach.

Cuando se observa una situación como ésta hay que escoger la codificación correcta a través de la lista desplegable Codificación de archivo que, como se ha indicado, aparece en la sección de Opciones avanzadas de este paso del proceso de importación.

De todos modos, en caso de que finalmente se importen los datos con la codificación errónea, siempre se le podrá indicar al CRM que la importación no ha sido correcta y que la deje sin efecto, pudiendo repetirla corrigiendo las opciones que sea necesario.

También es relevante indicar al CRM que el archivo subido contiene una fila de cabecera con los nombres de los campos, de manera que se pueda facilitar su relación posterior con los campos del CRM.

No es imprescindible que los nombres de los campos del listado subido coincidan exactamente con los del CRM mientras el usuario sea capaz de establecer las equivalencias correspondientes.


3) Relacionar las columnas del archivo subido con los campos del módulo del CRM

En este paso aparece una columna a la izquierda con todos los campos presentes en el archivo, una columna en el centro con los campos equivalentes del CRM y una tercera columna a la derecha con datos de ejemplo extraídos del primer registro del archivo.


2020-12-09 16h38 02.jpg


Así pues, habrá que indicar en la columna central sobre qué campos del CRM será necesario depositar los campos del archivo. Si hay coincidencia de nombres, el CRM ya mostrará directamente el campo oportuno. Si no es el caso, el usuario podrá hacer la selección manualmente.

Cabe tener en cuenta que SuiteCRM ofrece la posibilidad de importar solamente una dirección de correo electrónico en el caso de las organizaciones y dos en el caso de las personas. La incorporación de direcciones adicionales deberá realizarse manualmente a nivel de cada registro. En última instancia, aunque es una operación que requeriría conocimientos técnicos, se podrían insertar directamente en la base de datos mediante consultas semiautomatizadas.


4) Indicar, opcionalmente, la voluntad de detectar registros duplicados

En el último paso antes de la importación efectiva, el CRM permite indicar si se desea realizar un proceso de detección de duplicados en base a coincidencias en determinados campos clave (nombres, correos electrónicos, números de identificación, etc.). Si se considera necesario en función de la calidad percibida de los datos que se van a importar, se puede activar esta opción.


32.jpg


En caso de que el CRM detecte duplicados los presentará en pantalla y pedirá al usuario que determine el registro bueno o que genere una combinación de los valores disponibles en ambos registros.

Conviene tener presente que las operaciones de detección y fusión de duplicados se pueden hacer en cualquier momento y en cualquier módulo del CRM.


5) La importación se ha realizado

Antes de dar por terminado el proceso de importación, el CRM ofrece la posibilidad de validar los datos subidos y dar marcha atrás si se detecta algún tipo de error.


33.jpg


Igualmente, si el CRM detecta directamente algún tipo de problema que impide la importación de determinados registros (direcciones de correo electrónico inválidas, campos requeridos no disponibles, campos normalizados con valores erróneos, etc.), los lista aparte y ofrece la posibilidad de descargar un archivo sólo con estos registros para que el usuario los pueda corregir y volver a importar.

Siempre que se importen nuevos registros en el módulo de Compromisos de Pago, si deshacemos la importación realizada, debemos tener en cuenta que durante el proceso de importación, se habrán creado los pagos correspondientes al primer pago de cada uno de los compromisos de pago, por tanto deberemos eliminar esos pagos generados automáticamente durante la importación.


Actualización de registros

El proceso de importación de datos también sirve para actualizar registros ya existentes en el CRM. Los pasos son los mismos que los mencionados en Importación de datos, con unas diferencias en la preparación de los datos y en el primer paso.


Preparación de los datos a actualizar

Para hacer una actualización de datos se debe incluir en el archivo CSV el ID que el CRM haya asignado a cada registro. Consultar notas acerca de los ID de registros para ver las diferentes maneras posibles de obtener los ID de los registros.

Al hacer la importación con el ID, el CRM detectará que aquel registro ya existe y aplicará sobre él los datos importados.


Ejemplo actualizacion.jpg


En este caso, el CRM no hace uso del nombre como campo para actualizar datos de manera que si en algún registro no se incluye el ID, pero sí el nombre, el CRM lo detectará como duplicado y lo obviará o lo creará de nuevo.


Subir al servidor el archivo con los datos a importar

Este paso es el único que difiere de lo explicado en Importación de datos.

En este caso, una vez subido el archivo, se debe seleccionar la opción Crear y Actualizar Registros. Al hacer clic en "Siguiente" aparecerá una ventana emergente avisando de las implicaciones de actualizar datos.


Ventana emergente actualizacion datos.jpg


Los siguientes pasos a realizar son los ya mencionados anteriormente.

Cabe tener en cuenta que si un registro importado no contiene el ID, el CRM lo considerará un registro nuevo y así lo creará, salvo que se detecte como un posible duplicado si se hace uso de esta opción según se ha descrito anteriormente. Así pues, una importación estándar solo generará registros nuevos mientras que una importación de actualización puede, potencialmente, tanto crear como actualizar registros.


Orden de importación de los datos

Como regla general, conviene tener presente que es necesario importar primero aquellos módulos que contienen datos que serán utilizados posteriormente en otro módulo.

Veamos algunos ejemplos de secuencias de importación:

- Organizaciones -> Personas

- Personas -> Relaciones persona

- Organizaciones -> Relaciones organización

- Personas -> Compromisos de Pago -> Pagos

- Personas / Eventos -> Inscripciones


Las secuencias anteriores pueden combinarse entre sí:

Organizaciones -> Personas -> Compromisos de Pago -> Pagos


En síntesis, los datos se importarán según el orden siguiente:

- En primer lugar, las organizaciones.

- En segundo lugar, las personas.

- A continuación, el resto de módulos, priorizando aquellos cuyos datos van a ser utilizados en importaciones posteriores de otros módulos para la creación de relaciones.

Si al importar datos de módulos relacionados el CRM no encuentra en los módulos correspondientes los registros que esperaría encontrar para generar las relaciones, creará los registros necesarios de forma implícita.

Por ejemplo, si se importa un listado de personas y una de esas personas está asociada a una organización que no aparece en el módulo de Organizaciones, el CRM creará primero la organización (sólo con el nombre, ya que no tendrá otros datos), luego importará la persona y finalmente creará el vínculo entre ambas.

Para evitar posibles duplicidades de datos relacionados (al importar personas, se cree una nueva organización, por ejemplo), lo más aconsejable es indicar la organización por su ID y no por su nombre, podría suceder que aún siendo la misma organización, en varias filas su nombre estuviese indicado de forma diferente, "La Cosa SA", "La Cosa S.A.", esto daría lugar a que el CRM creara uno o más nuevos registros de organizaciones, al importar Personas.


Ejemplos de importación de datos

Personas y Relaciones con personas

1) Supongamos que se dispone de un listado de voluntarios:


Importar ej01 img01 voluntarios.jpg


2) Y también de un listado de patronos:


Importar ej01 img02 patronos.jpg


3) Primero se importarán, por ejemplo, los voluntarios. Tal y como están los datos el listado ya es correcto, no hay que realizar ninguna operación previa especial de preparación; simplemente cargar el listado en el módulo Personas del CRM, mapeando los campos oportunamente según lo explicado en el apartado Importación de datos.

Si, por ejemplo, los campos Nombre y Apellidos estuvieran juntos en una única celda sería aconsejable separarlos en la hoja de cálculo antes de importar los datos al CRM.

Es importante notar que en el listado a importar no se hace referencia alguna a la condición de voluntarios de dichas personas. Esta información se reflejará posteriormente en el módulo de Relaciones con personas.


4) Una vez creadas las personas mediante la importación anterior, deberán crearse las relaciones mediante una importación en el módulo Relaciones con personas. Para ello se define un listado como el siguiente:


Importar ej01 img03 relaciones voluntarios.jpg


Cabe observar que existe un campo Persona resultado de unir los campos Nombre y Apellidos del listado original de voluntarios. Esta unión se puede conseguir fácilmente en Excel mediante una fórmula del tipo =CONCATENAR(A2;" ";B2), donde A2 y B2 serían las celdas que contienen, respectivamente, el nombre y los apellidos de la primera persona de la lista. Entre nombre y apellidos se añade un espacio en blanco para que no queden los textos pegados. Disponer de este campo Persona (con el nombre completo) es necesario para que cuando se realice la importación de las relaciones el CRM sea capaz de vincular adecuadamente cada relación con la persona correspondiente previamente importada.

Igualmente, se incorpora un campo Nombre, que en este caso corresponde al nombre de la relación (recordemos que se desea importar datos al módulo Relaciones con personas). Este campo podría contener cualquier valor (el CRM siempre requiere disponer de un campo Nombre en cualquier módulo), pero para que sea algo representativo se crea mediante una concatenación similar a la anterior, uniendo el nombre completo de la persona (que se ha obtenido en la concatenación anterior) y el Tipo de relación.

Cabe insistir en la idea de que en todos los módulos del CRM debe existir un campo Nombre que el CRM utilizará, por ejemplo, para enlazar a la vista de detalle de cualquier registro desde cualquier punto del sistema. Por esta razón, al crear un registro o al realizar una importación en cualquier módulo siempre debe indicarse un valor para el campo Nombre, aunque semánticamente (como en el caso de las relaciones que estamos describiendo) no sea un dato relevante en cuanto a aporte de información.


5) Se importa el listado anterior cargándolo en el módulo Relaciones con personas y mapeando los campos oportunamente. Como se indicaba en el punto anterior, el campo Persona (equivalente al nombre completo de la persona) es clave en este punto del proceso porque es el dato que va a permitir al CRM vincular la relación que se está creando con la persona adecuada que ha sido creada previamente al importar el listado inicial de voluntarios en el punto 3).

Después de realizar esta operación, en la vista de detalle de una persona debería apreciarse como en el subpanel de relaciones aparece la de voluntariado que se acaba de crear. Igualmente, debería aparecer el valor Voluntario en el campo Tipo de relación de la parte principal de la ficha.

Nota: Por claridad en el ejemplo se han generado dos listados (personas voluntarias y relaciones de voluntariado), pero no hay ninguna necesidad de que sean dos listados separados en dos ficheros distintos. Se podrían haber añadido en el primer listado los campos necesarios para generar el segundo y mantener un único listado. Finalmente, al realizar las importaciones, se habrían elegido en cada caso las columnas relevantes.


6) Se procede a continuación con el listado de patronos. Se observa que en el listado hay una persona, Pedro Fernández, que ya fue dada de alta en el CRM al importar los voluntarios. Cabe eliminar, pues, a esta persona del listado de patronos y proceder a la importación del resto en el módulo de Personas, igual como se hizo con los voluntarios en el punto 3).


Importar ej01 img04 patronos sin duplicados.jpg


7) Finalmente, se importarán las relaciones de tipo patrón de forma análoga a como se importaron las de tipo voluntario en el punto 5), con un listado como el siguiente:


Importar ej01 img05 relaciones patronos.jpg


Cabe observar que en el listado de relaciones sí vuelve a aparecer Pedro Fernández. En el módulo de Personas sólo debe figurar una vez, de ahí que no lo importáramos al importar el listado de patronos, pero en el módulo de Relaciones aparecerán dos a su nombre, una como voluntario y otra como patrón.


Personas, Compromisos de Pago y Pagos

El proceso de importación de compromisos de pago, muy habitual cuando se traspasan al CRM listados de socios y donantes, es bastante similar al ya descrito para las relaciones con personas.

1) Inicialmente se importarán los datos de las personas, verificando que no se introducen duplicados.

2) A continuación se importarán los datos de los compromisos de pago. Para vincular los compromisos de pago con las personas adecuadas es necesario que en el listado de Compromisos de Pago aparezca una columna Persona (nombre completo de la persona) o Persona ID (Identificador de la persona) tal y como se ha descrito en el ejemplo anterior. También será necesario un campo Nombre para el Compromiso de pago (ver, de nuevo, el ejemplo anterior).

Los campos que como mínimo deberían importarse son los siguientes: Nombre (del compromiso de pago), Persona (u Organización), Tipo de pago, Medio de pago, Importe, Frecuencia y Fecha de primer pago. Si el Medio de pago es Domiciliación será necesario importar también Número de cuenta y Mandato.

3) Cabe tener en cuenta que al importar los compromisos de pago se van a crear los primeros pagos vinculados a esos compromisos de pago (ver Pago inicial y estado de los pagos). En este sentido, no será necesario importar pagos futuros de forma explícita, puesto que una vez creado el compromiso de pago y el primer pago, el CRM se encargará de la generación sucesiva de nuevos pagos (ver Compromisos de Pago, Pagos y Remesas - Planificador y pagos recurrentes).

4) Si se importa un compromiso de pago con una Fecha de primer pago en el pasado se crearán también automáticamente todos los pagos pertinentes desde esa fecha hasta la actual, según la periodicidad establecida. Si existe una Fecha de baja, el CRM creará automáticamente los pagos pertinentes entre la Fecha de primer pago y la Fecha de baja.

5) En la imagen siguiente se muestra una posible estructura de los datos a importar.


Ejemplo importación cdp.jpg


Histórico Modelo 182

El ejemplo anterior puede servir para cargar en el CRM un histórico de los pagos incluidos en el Modelo 182 de los dos ejercicios previos al de empezar a usar el CRM, de modo que puedan tenerse en cuenta en el momento de determinar la condición de donante recurrente en las futuras declaraciones del M182 que ya se generen desde el CRM.

En este caso, en lugar de crear los compromisos de pago con la periodicidad que toque, se recomienda crear un compromiso de pago por año y por persona con periodicidad "Puntual" en el que se recoja el total del importe de los pagos que realizó la persona en un año en concreto. Al importarlo a SinergiaCRM, tan solo se generará el compromiso de pago y un pago.

De esta manera, si en alguno de los años anteriores hubo alguna particularidad que hizo que alguien no pagara el total que le tocaría por su (Importe * Periodicidad), no se tendrá que ir uno a uno a comprobar que cuadre lo que se tiene en las cuentas anteriores y lo que ha quedado registrado en el CRM.

Pongamos por caso que durante el año 2020 se redujeron algunas cuotas porque la pandemia de la COVID-19 impidió hacer las actividades de manera normal. En este caso, al cargar un compromiso de pago con, por ejemplo, fecha de alta en 2019 y periodicidad "Mensual", se generarán todos los pagos por cada mes y por el mismo importe. Entonces es posible que si vamos a mirar el total del 2020 que consta en el CRM no sea el mismo que el que se tiene en las cuentas, ya que no se habrá tenido en cuenta que las cuotas de marzo y abril no se cobraron, por ejemplo. De esta manera, cargar el total anual permite controlar que el total que indique el CRM coincida con las cuentas que se tiene de los años anteriores.


Historico 182.jpg


Migración de datos entre campos

Es posible en algún momento se desee cambiar el tipo de datos de un campo existente. Como no es posible modificarlo en Estudio, se puede hacer un proceso de migración de datos entre el campo original y uno de nueva creación con el tipo deseado.

A continuación se describirá el proceso para pasar los datos de un campo de tipo texto a uno desplegable, aunque se puede aplicar a cualquier combinación de tipos de campos:

1) Buscar en el campo original los diferentes valores que aparezcan y unificar aquellos que puedan ser similares.

2) Crear la lista desplegable con los valores obtenidos en el paso anterior. Ver Gestión de listas desplegables.

3) Crear el campo nuevo con el tipo deseado, en este caso Desplegable. Relacionarlo con la lista desplegable creada en el punto anterior.

4) Exportar los registros que tengan algún valor en el campo original. En el fichero exportado, eliminar todos los campos a excepción de los campos requeridos en la importación, del ID del registro y del campo antiguo que se desea migrar. Substituir los valores de la columna antigua por su nuevo valor de la lista desplegable y cambiar el nombre de la columna por el del campo nuevo.

Para más información sobre el manejo de los ficheros CSV generados por el CRM, se recomienda consultar el apartado Visualización de datos exportados (.csv) en Excel.

5) Hacer una importación del tipo Crear y actualizar registros.

6) Una vez se haya comprobado que los valores entre ambos campos coinciden, se puede ocultar de las vistas el campo antiguo y dejar solamente el de nueva creación o, incluso, valorar su eliminación para evitar futuras confusiones.


Volver al índice