Addons a medida / 4198 - ESOFITEC GLOBAL SOLUTIONS, S.L. / Sit.Sync.Smg

Datos sincronizados

Todo lo que llega a Salesmanago sale de la vista SalesmanagoContacts de la base de datos ESOFITEC_OTRS. La vista devuelve una fila por relación de contacto con los datos ya compuestos en cuatro bloques: datos del contacto, propiedades estándar, propiedades de diccionario y etiquetas. El ejecutable los recoge y los envía tal cual, con una única transformación propia: el saneado de los literales de las etiquetas.

Esto tiene una consecuencia práctica para soporte: si hay que cambiar qué se informa en una propiedad o añadir una etiqueta nueva, se modifica la vista y nada más. Este artículo describe lo que la vista genera en su versión actual y de qué tablas y campos de la empresa ESOFITEC lo obtiene.

Qué contactos entran#

La vista parte de __CONTACTOSRELACION unida a __CONTACTOS y se queda con las relaciones que cumplen las tres condiciones: la entidad es un cliente (IDTIPOENTIDAD = 1) o un cliente potencial (IDTIPOENTIDAD = 3), y el correo (EMAIL) de la relación no es nulo ni está en blanco.

Un mismo contacto de __CONTACTOS con relaciones en dos clientes aparece dos veces, una por relación, y llega a Salesmanago como dos contactos distintos. La empresa ESOFITEC tiene una restricción de unicidad sobre el correo de __CONTACTOSRELACION, así que dos relaciones nunca comparten correo y cada fila de la vista se corresponde con un único contacto de Salesmanago.

Las relaciones marcadas como obsoletas (OBSOLETO) también entran en la vista: se envían con normalidad y, además, el sincronizador les fuerza el opt-out.

Datos del contacto#

Campo en Salesmanago	Origen en a3ERP
`email`	`__CONTACTOSRELACION.EMAIL`
`name`	`__CONTACTOS.NOMBRE` seguido de `APELLIDOS` si está informado
`phone`	El primero informado de: teléfono 1 de la relación, teléfono 1 del contacto, `CLIENTES.TELCLI` o `CLIENTESPOT.TELPOS`
`fax`	El primero informado de: teléfono 2 de la relación, teléfono 2 del contacto, `CLIENTES.TELCLI2` o `CLIENTESPOT.TELPOS2`
`company`	`CLIENTES.NOMCLI` o `CLIENTESPOT.NOMPOS`
`externalId`	`CLIENTES.CODCLI` sin espacios a la izquierda. Vacío en clientes potenciales
`state`	`CUSTOMER` si la entidad es un cliente, `PROSPECT` si es un potencial
`address.streetAddress`	`CLIENTES.DIRCLI1` o `CLIENTESPOT.DIRPOS1`
`address.zipCode`	`CLIENTES.DTOCLI` o `CLIENTESPOT.DTOPOS`
`address.city`	`CLIENTES.POBCLI` o `CLIENTESPOT.POBPOS`
`address.country`	Código ISO 3166 de dos letras del país del cliente o potencial (`PAISES.CODISO3166A2`)

En la actualización de un contacto existente se envían los mismos campos salvo email, que identifica al contacto y no se modifica.

Propiedades estándar#

En Salesmanago aparecen en el bloque Standard details de la ficha del contacto. Cada una se envía como una pareja nombre y valor, y solo se incluye si el dato está informado.

Nombre	Valor	Origen
`Facturacion`	Descripción de la característica 6 de organización	`CARACTERISTICAS.DESCCAR` para `CAR6_ORG` del cliente o potencial
`Sector`	Descripción de la característica 7 de organización	`CARACTERISTICAS.DESCCAR` para `CAR7_ORG`
`Trabajadores`	Descripción de la característica 8 de organización	`CARACTERISTICAS.DESCCAR` para `CAR8_ORG`
`Clasificacion`	Código de la característica 10 de organización	`CLIENTES.CAR10_ORG` o `CLIENTESPOT.CAR10_ORG`
`Fase`	Fase comercial	En clientes, `CLIENTES.PARAM1`. En potenciales, el literal `C` (fase Creinsa) cuando `CLIENTESPOT.CAR8_ORG` vale `FASEC`

Propiedades de diccionario#

Son las propiedades numéricas o de fecha que Salesmanago muestra en Dictionary details y que permiten segmentar por rangos. Todas las actuales son de tipo NUMBER.

Nombre	Valor	Cuándo se envía
`ValorCartera`	Importe anualizado de los mantenimientos vivos del cliente, redondeado al alza al entero	Solo clientes. Ver cómo se calcula
`Facturacion`	Primer carácter del código `CAR6_ORG` si es un dígito; `0` en caso contrario o si no hay característica	Siempre
`EnvioFactura`	`1` si el correo de la relación aparece dentro de `CLIENTES.E_MAIL_DOCS`; `0` si no	Siempre. En potenciales es siempre `0`

La propiedad Facturacion se envía dos veces con nombres iguales pero en bloques distintos: como propiedad estándar lleva la descripción de la característica y como propiedad de diccionario lleva un dígito para poder filtrar por tramo. El dígito sale del código de la característica, así que la parametrización de la característica 6 de organización debe mantener códigos que empiecen por cifra.

Cómo se calcula el valor de cartera#

Se suman las líneas de cuota de Sit.Sat vivas del cliente: SIT_SAT_LINEA_CUOTA unida a SIT_SAT_CABE_CUOTA y SIT_SAT_CABE_PROY, donde el proyecto pertenece al cliente (SIT_SAT_CABE_PROY.CODCLI), ni la cabecera ni la línea están de baja (SIT_SAT_BAJA distinto de T) y el artículo pertenece a la familia estadística de mantenimientos (ARTICULO.CODFAMEST = 2).

De cada línea se toma SIT_SAT_UNIDADES por SIT_SAT_PRCMONEDA, se aplican en cascada los cuatro descuentos SIT_SAT_DESC1 a SIT_SAT_DESC4 y se anualiza según la periodicidad de la cabecera (SIT_SAT_PERIODICIDAD):

Periodicidad	Multiplicador
`M` (mensual)	12
`B` (bimestral)	6
`T` (trimestral)	4
`S` (semestral)	2
Cualquier otra (anual)	1

El total se redondea al alza al entero. Un cliente sin mantenimientos vivos envía 0.

Etiquetas#

Las etiquetas son el dato más importante para marketing porque son el criterio de segmentación de las campañas. La vista genera dos grupos: las que aplican tanto a clientes como a potenciales y las que solo tienen sentido para clientes, porque dependen de los mantenimientos contratados.

Etiquetas de cliente y de potencial#

Etiqueta	Cuándo se envía	Valor
`EMPR-<empresa>`	Siempre	`CLIENTES.NOMCLI` o `CLIENTESPOT.NOMPOS`
`REPR-<representante>`	Si el cliente o potencial tiene representante	`REPRESEN.NOMREP` del `CODREP` de la ficha
`RUTA-<ruta>`	Si tiene ruta	`RUTAS.NOMRUTA`
`DEPT-<cargo>`	Si la relación tiene cargo o, en su defecto, lo tiene el contacto	`__CARGOS.DESCRIPCION`
`PART-NO-ENVIAR`	Si el cliente o potencial tiene representante 3 (`CODREP3`) en su ficha, o el cliente lo tiene en algún proyecto de Sit.Sat con mantenimiento vivo	Literal fijo
`REP3-<representante 3>`	Una por cada representante 3 distinto: el de la ficha y los de los proyectos con mantenimiento vivo	`REPRESEN.NOMREP` del `CODREP3`. Si el código de representante es mayor que `900` se quitan los dos primeros caracteres del nombre. En ambos casos se pasa por la función `dbo.QuitarCaracteresEspeciales` de `ESOFITEC_OTRS`

El representante 3 identifica al partner que gestiona la cuenta. PART-NO-ENVIAR sirve para excluir de las campañas directas a los contactos de clientes que llegan a través de un partner, y REP3- permite segmentar por partner concreto.

Etiquetas solo de cliente#

Etiqueta	Cuándo se envía	Valor
`MANT-ACTIVO`	Si el cliente tiene algún mantenimiento vivo	Literal fijo
`MANT-BAJA`	Si el cliente no tiene ningún mantenimiento vivo y sí alguno de baja	Literal fijo
`MANT-<producto>`	Una por cada producto con mantenimiento vivo	`ARTICULO.CAR3` (característica 3 del artículo, que en ESOFITEC es el producto) sin espacios
`BAJA-<producto>`	Una por cada producto con alguna línea de mantenimiento de baja	`ARTICULO.CAR3` sin espacios
`ARTI-<artículo>`	Una por cada artículo con mantenimiento vivo	`ARTICULO.DESCART`

MANT-BAJA solo aparece cuando el cliente no conserva ningún mantenimiento vivo, pero BAJA-<producto> se genera para cualquier producto que tenga alguna línea de baja, aunque ese mismo producto tenga otras líneas vivas y también lleve su MANT-<producto>.

Qué se considera mantenimiento vivo#

Todas las etiquetas de mantenimiento y el valor de cartera usan el mismo criterio. Un mantenimiento vivo es una línea de SIT_SAT_LINEA_CUOTA tal que:

pertenece a una cabecera SIT_SAT_CABE_CUOTA de un proyecto SIT_SAT_CABE_PROY cuyo CODCLI es el del cliente,
ni la cabecera ni la línea tienen SIT_SAT_BAJA = 'T',
y su artículo tiene CODFAMEST igual a 2, la familia estadística de mantenimientos.

Un mantenimiento de baja es la misma línea con SIT_SAT_BAJA = 'T' en la cabecera o en la línea.

Saneado de las etiquetas#

Salesmanago solo admite en las etiquetas números, letras mayúsculas sin acento y los caracteres ( [ { ) ] } _ -. Los nombres de empresa, representante o artículo de a3ERP no cumplen eso, así que el ejecutable transforma cada literal, en este orden:

Lo pasa a mayúsculas.
Quita los acentos y diacríticos (Ñ pasa a N).
Elimina los puntos y las comas.
Sustituye por _ cualquier otro carácter no admitido, incluidos los espacios.
Colapsa las secuencias de varios _ seguidos en uno solo.

Así, EMPR-Esofitec Global Solutions, S.L. se envía como EMPR-ESOFITEC_GLOBAL_SOLUTIONS_SL, y ARTI-a3EQUIPO Intranet de 101 a 200 licencia de uso como ARTI-A3EQUIPO_INTRANET_DE_101_A_200_LICENCIA_DE_USO.

El filtro de caracteres admitidos deja pasar también : ; < = > ? @, que quedan en la etiqueta sin sustituir. Si un nombre de empresa o de artículo los contiene, Salesmanago puede rechazar la etiqueta y el error aparecerá en el correo de resumen.

Qué etiquetas gestiona el sincronizador#

Después del saneado, el ejecutable descarta las etiquetas que no cumplen la expresión regular Salesmanago.RegexPatternCustomTags de la configuración. Ese patrón es el que le permite convivir con las etiquetas creadas a mano en Salesmanago: solo añade y quita las que lo cumplen.

El patrón configurado en producción es ^[0-Z]{4}-.+: exactamente cuatro caracteres alfanuméricos, un guion y cualquier cosa detrás. Lo cumplen todas las etiquetas actuales de la vista, porque todas tienen un prefijo de cuatro caracteres: EMPR-, REPR-, RUTA-, DEPT-, REP3-, PART-, MANT-, BAJA- y ARTI-. El descarte es silencioso: una etiqueta que no cumpla el patrón no genera error ni aparece en el correo de resumen, simplemente no viaja.

Toda etiqueta nueva debe tener prefijo de cuatro caracteres y guion

Al añadir una etiqueta a la vista hay que darle un prefijo de exactamente cuatro caracteres seguido de guion. Una etiqueta como PARTNER-NO-ENVIAR (siete caracteres antes del guion) se genera en la vista pero el ejecutable la descarta, y nadie se entera hasta que marketing la echa en falta. Es la causa más habitual de "la vista la genera pero en Salesmanago no aparece". La alternativa de ampliar RegexPatternCustomTags con literales sueltos funciona, pero cualquier etiqueta manual de Salesmanago que también cumpla el patrón nuevo pasaría a estar gestionada por el sincronizador y se borraría si a3ERP no la genera.

Formato interno de la vista#

Para quien tenga que modificar la vista: los tres bloques compuestos se devuelven como una única cadena por columna, con los elementos separados por ::.

Columna de la vista	Formato de cada elemento	Ejemplo
`properties`	`Nombre-Valor`, separando en el primer guion	`Facturacion-De 1 a 3 M::Sector-Servicios`
`dictionaryProperties`	`Nombre-Tipo-Valor`, con tipo `NUMBER` o `DATE`	`ValorCartera-NUMBER-12500::EnvioFactura-NUMBER-1`
`tags`	Literal de la etiqueta, prefijo incluido	`EMPR-Empresa Ejemplo::REPR-Nombre Apellido`

Los valores NUMBER deben ser enteros. Los valores DATE se escriben como dd/MM/yyyy y se convierten a marca de tiempo Unix al enviarlos; en la vista queda comentado un ejemplo con la fecha de alta de la relación. El nombre de una propiedad no puede contener guiones porque el corte se hace en el primero; el valor sí puede.