Cambios en SinergiaCRM entre las versiones de SugarCRM y SuiteCRM

From SinergiaCRM - Wikisuite
Jump to navigation Jump to search

Introducción

En julio de 2020 se han puesto en funcionamiento las primeras instancias de SinergiaCRM que operan sobre la base de SuiteCRM. En el otoño siguiente se ha iniciado la migración de las instancias que operaban sobre SugarCRM hacia la nueva plataforma. Al margen de las novedades y mejoras que SuiteCRM aporta, es importante que las personas usuarias que han trabajado en el pasado con la versión que operaba sobre SugarCRM sean conscientes de algunos cambios introducidos en la capa de servicio específica de SinergiaCRM. Los más relevantes se describen a continuación.


Aspectos transversales

Campos eliminados

Con el fin de mantener un interfaz y un sistema lo más sencillos posible, en algunos módulos se han eliminado campos que no han tenido un uso significativo por parte de las entidades, que resultaban confusos, que han dejado de tener uso por la evolución de la aplicación o para los que nunca se ha llegado a implantar la funcionalidad prevista. En cualquier caso, estos campos han sido conservados en el caso de aquellas entidades que sí habían almacenado datos en ellos.

  • Organizaciones: Código, Facebook, Linkedin, Twitter, Teléfono alternativo y los relativos a direcciones postales desagregadas ya indicados.
  • Personas: Agenda, Código, Comentarios (fusionado con Descripción), Disponibilidad, Facebook, Googlemas, Linkedin, Twitter y los relativos a direcciones postales desagregadas ya indicados.
  • Relaciones con Personas: Observaciones (fusionado con Descripción).
  • Interesados: Comentarios (fusionado con Descripción), Facebook, Googlemas, Linkedin, Twitter, Importe, Medio de pago, Número de cuenta, Periodicidad, Tipo de pago, Tipo, Subtipo y los relativos a direcciones postales desagregadas ya indicados.
  • Compromisos de Pago (antes Formas de Pago): Número de referencia de tarjeta, Año de caducidad, Mes de caducidad, Estado y Origen. Además, el campo Día de presentación pasa a llamarse Segmentación.
  • Pagos: Devolución tarjeta, Número de referencia de tarjeta, Fecha del donativo y Fecha de anulación.
  • Remesas: Fecha de la remesa.
  • Eventos: Conclusiones y los relativos a las ubicaciones ya indicados.


Validaciones reforzadas

En algunos módulos se han introducido nuevas validaciones de datos en las vistas editables con el fin de mejorar la consistencia interna de los datos almacenados. A modo de ejemplo, en aquellos módulos en los que se dispone de la pareja de campos Fecha de inicio/fin, se validará que la segunda sea posterior a la primera. Por otro lado, en los módulos de Personas e Interesados se validará que exista consistencia entre los campos Tipo de identificación y Número de identificación, de modo que no pueda indicarse uno sin indicarse el otro y asegurando que el tipo y el número indicados se corresponden correctamente.

Además, en los casos en que una validación afecta a más de un campo a la vez, se ha incorporado un indicativo visual en aquellas vistas en las que el hecho de que uno de los campos no esté disponible imposibilite la validación combinada. Por ejemplo, en la captura siguiente, correspondiente a la vista de edición del módulo Personas, se ha ocultado el campo Tipo de identificación. Ello ha provocado que junto a la etiqueta del campo Número de identificación aparezca un símbolo de alerta. Al colocar el cursor sobre el símbolo podrá leerse el siguiente texto: "La validación de este campo depende de un campo que no está visible. Si desea que esta validación se aplique solicite al administrador del CRM que incluya en la vista este campo: · Tipo de identificación".

Validacion combinada.png

En este caso no se podría validar el dato introducido en el campo Número de identificación porque para ello sería necesario conocer el Tipo de identificación, que no está disponible.


Cambios en nombres de módulos, campos y listas desplegables

En el cambio de versión algunos módulos y campos, así como algunas listas desplegables y sus valores, han modificado su denominación. Aunque para los usuarios del CRM en general, incluidos los administradores, estos cambios son transparentes, es posible que para terceros desarrolladores de sitios web u otras aplicaciones que se conectan con el CRM mediante formularios, API u otras vías estos cambios sean de interés. Mediante el siguiente enlace puede accederse a una hoja de cálculo en la que están detallados todos los nombres que han sufrido algún cambio.

Cambios en los nombres de módulos, campos y listas desplegables


Organizaciones, Personas e Interesados

Fusión de los campos desagregados de direcciones postales

En la versión de SinergiaCRM sobre SugarCRM las direcciones postales de los módulos Organizaciones, Personas e Interesados se almacenaban de forma desagregada en una estructura formada por los campos Tipo de vía, Vía, Número, Escalera, Piso, Puerta, Código postal, Población, etc.).

Sin embargo, esta no era la forma nativa de gestionar las direcciones postales por parte de SugarCRM, como tampoco lo es para SuiteCRM. Ambas operan de serie con un único campo llamado Dirección para almacenar los campos que van desde Tipo de vía hasta Puerta, continuando posteriormente con los ya mencionados Código postal, Población, etc.

En su momento SinergiaCRM decidió adoptar la estructura desagregada ya mencionada pero a lo largo del tiempo se ha observado que para la práctica totalidad de entidades usuarias no aportaba ningún beneficio y, al mismo tiempo, suponía la necesidad de mantener determinados mecanismos de sincronización entre ambos sistemas para aprovechar la funcionalidad que la plataforma base incorporaba en relación a la gestión de las direcciones postales.

Así pues, aprovechando el cambio de plataforma se ha restituido el funcionamiento original de este aspecto del CRM, agregando en el campo Dirección los datos que antes se repartían, como ya se ha indicado, desde Tipo de vía hasta Puerta.


Tipo de relación

El antiguo campo Tipo de relación que aparecía en los módulos de Personas y Organizaciones pasa a llamarse Tipos de relaciones actuales. Su uso y sentido es el de siempre, pero con el cambio de denominación quedará más claro qué datos contiene. Como el usuario ya sabrá, este campo se gestiona de forma automática por parte del CRM a partir de los datos contenidos en los módulos de Relaciones con Personas/Organizaciones. Además de optimizar su nombre el campo ha sido escondido de las vistas editables, a fin de evitar algunas confusiones en cuanto a su manejo que históricamente se habían producido. Así pues, se refuerza la idea que se trata de un campo de solo lectura.


Economía

De Formas de Pago a Compromisos de Pago

El módulo Formas de Pago pasa a llamarse Compromisos de Pago. La anterior denominación no era suficientemente precisa y al mismo tiempo podía causar cierta confusión con el concepto Medio de pago (el mecanismo a través del cual se realiza el pago). Así pues, en la versión actual el módulo pasa a denominarse Compromisos de Pago, que describe mucho mejor el concepto que almacena (datos económicos genéricos que se verán confirmados en los pagos concretos asociados a ese compromiso) y que evita la confusión mencionada.


Optimización de la generación de remesas bancarias

En el módulo Remesas se ha eliminado definitivamente la funcionalidad asociada al obsoleto Cuaderno 19 en formato texto plano. Los datos de las remesas que en su momento fueron generadas en el CRM se mantienen, pero ya no será posible generar ficheros basados en esa norma, quedando solamente disponible el formato SEPA XML. Con este cambio desaparece también el campo Fecha de la remesa, que no se usa para la generación de las remesas SEPA.

Se ha eliminado también la restricción que impedía cambiar libremente el Estado de la remesa. De este modo, en caso de necesidad se podrá reabrir una remesa ya generada o enviada que por cualquier razón precise de cambios.

Finalmente, en el proceso de generación de ficheros de remesas se han introducido diferentes mecanismos de validación que informan con detalle de potenciales errores, de modo que se bloquea su generación hasta que dichos errores hayan sido subsanados. Así, se reduce notablemente el riesgo de que el fichero sea rechazado por un aplicativo bancario y el usuario deba regresar al CRM a investigar los motivos del error.


Eliminación de las relaciones entre Subvenciones y Personas/Organizaciones destino

En la versión anterior de SinergiaCRM existían dos relaciones entre el módulo Subvenciones y los módulos Personas y Organizaciones que se usaban para indicar cuál era la persona o la organización destinataria de los recursos de esa subvención que la entidad usuaria del CRM había logrado. Sin embargo, así como en el módulo Formas de Pago este relación de destinación económica tiene sentido y es ampliamente utilizada, en Subvenciones no encajaba bien conceptualmente, por lo que se ha retirado. Como en el caso de los campos eliminados, se han conservado estas relaciones en las instancias que estuvieran haciendo uso de ellas.


Eventos

De inscripciones a asistentes

En la versión anterior de SinergiaCRM se asumía que cada inscripción a un evento implicaba la participación de una única persona en ese evento, la que figuraba en la propia inscripción. Sin embargo en algunas ocasiones un evento requiere que una inscripción incluya varias personas asistentes. Así, se ha incorporado el campo Asistentes al módulo Inscripciones. Este campo tendrá por defecto valor 1, pudiéndose indicar cualquier valor superior de ser necesario. A su vez, en el módulo Eventos los campos que anteriormente totalizaban las inscripciones por estado ahora contabilizan asistentes por estado e igualmente en base al número de asistentes se determina el envío de notificaciones del 80% y del 100% de plazas cubiertas cuando el aforo es limitado. A pesar de estos cambios, nótese que en la medida que las inscripciones sigan siendo unipersonales el comportamiento de los módulos será equivalente al de la versión anterior.


Ubicaciones de eventos

En la versión anterior el módulo Eventos disponía de una serie de campos para registrar la dirección completa del lugar en el que se celebraba un evento. En la nueva versión dichas direcciones se han traspasado al nuevo módulo Ubicaciones, de modo que no es necesario repetir los datos completos para eventos que se celebran en la misma ubicación, sino que basta con asignar una ubicación existente al nuevo evento como en cualquier otro par de módulos relacionados.


Administración del CRM

Security Suite por defecto

La nueva versión de SinergiaCRM incorpora por defecto el módulo Security Suite que permite la gestión avanzada de los roles de acceso a la información del CRM. Anteriormente, este módulo sólo se instalaba en las instancias de aquellas entidades que lo solicitaban específicamente porque su casuística así lo demandaba. En SuiteCRM este es un módulo estándar, de modo que está disponible en todas las instancias.


Menos constantes, más claras... y se llaman Configuración

El antiguo módulo Constantes ha sido renombrado como Configuración. Además, las más de 60 claves que solían aparecer en las instancias anteriores se han reducido a menos de la mitad, de modo que solamente aquellas que realmente sean susceptibles de ser configuradas por la entidad aparezcan en el módulo. Ello simplificará la parametrización general del CRM y evitará posibles incidencias.

Constantes con cambio de nombre significativo

- Las antiguas constantes M182_DECLARANTE, SEPA_CREDIT_NAME, SEPA_DEBTOR_NAME y SEPA_PARTY_NAME han sido reemplazadas por GENERAL_ORGANIZATION_NAME, que contiene el nombre de la entidad. Cualquier proceso en el que sea necesario usarlo lo obtendrá siempre de esta clave.

- Un caso similar es el de M182_NIF, reemplazada por GENERAL_ORGANIZATION_ID.

- Otras constantes SEPA que han cambiado:

  • SEPA_BIC_NUMBER => SEPA_BIC_CODE
  • SEPA_MODO_BIC => SEPA_DEBIT_BIC_MODE
  • SEPA_CONCEPTO_OBG_INDIVIDUAL => SEPA_DEBIT_DEFAULT_REMITTANCE_INFO
  • SEPA_CONCEPTO_OBG_INDIVIDUAL_PAGOS => SEPA_TRANSFER_DEFAULT_REMITTANCE_INFO
  • SEPA_CREDIT_SCHEME_IDENTIFICATION / SEPA_OIN_NUM => SEPA_DEBIT_CREDITOR_IDENTIFIER

Constantes eliminadas

- Todas las relativas al antiguo Cuaderno19, actualmente obsoleto.

- Las siguientes constantes relativas a los porcentajes de deducción fiscal usadas en el Modelo 182 han sido incluidas directamente en el código de la aplicación, pues son valores fijos que no dependen de la entidad:

  • M182_PORCENTAJE_DEDUCCION
  • M182_PORCENTAJE_DEDUCCION_CUOTAS_PARTIDOS
  • M182_PORCENTAJE_DEDUCCION_EXCESO_NO_RECURRENTE
  • M182_PORCENTAJE_DEDUCCION_EXCESO_RECURRENTE
  • M182_PORCENTAJE_DEDUCCION_PERSONAS_JURIDICAS
  • M182_PORCENTAJE_DEDUCCION_PERSONAS_JURIDICAS_RECURRENTE

- Las siguientes constantes relativas a las pasarelas de pago han sido incluidas directamente en el código de la aplicación, pues son valores fijos que no dependen de la entidad:

  • PAYPAL_URL
  • PAYPAL_URL_TEST
  • TPV_SERVER
  • TPV_SERVER_TEST
  • TPV_VERSION
  • TPV_VERSION_TEST


Interfaz

Nuevo menú de usuario

El antiguo menú de usuario, presente en la esquina superior derecha del CRM, se ha reforzado con la incorporación de enlaces a la wiki, al canal de vídeos y a los foros de SinergiaCRM, de modo que resulte más sencillo el acceso a cualquiera de estos recursos mientras se utiliza el CRM.