Compromisos de pago, Pagos y Remesas

From SinergiaCRM - Wikisuite
Jump to navigation Jump to search

Conceptos básicos

SinergiaCRM no es propiamente una herramienta de planificación económica, pero permite la gestión de algunos aspectos relacionados con los flujos económicos de las entidades usuarias. Como se verá a lo largo de este capítulo, SinergiaCRM puede gestionar tanto movimientos relacionados con ingresos como con gastos. Sin embargo, dado que los usos y las necesidades más habituales son en relación a los ingresos, la mayor parte de la documentación se referirá a este tipo de movimientos.

En nuestro canal de Youtube tenéis a vuestra disposición un vídeo formativo sobre los módulos de Compromisos de pago (antes llamados Formas de Pago), Pagos y Modelo 182



y uno sobre los conceptos básicos del módulo de Remesas.



A nivel conceptual, el proceso de gestión de los pagos, ya sean puntuales (donativos o de otra índole) o recurrentes (cuotas de socios, donaciones periódicas, pagos de servicios periódicos, etc), se lleva a cabo desde un enfoque a dos niveles:

- Compromiso de pago: es el compromiso que adquiere una persona u organización para llevar a cabo una aportación. A modo de ejemplo: cuota mensual de 10€ domiciliada o aportación puntual de 200€ vía transferencia. El concepto compromiso de pago permite, por ejemplo, calcular aportaciones globales anualizadas para las cuotas periódicas y, en consecuencia, disponer de una estimación de los ingresos futuros por este concepto. Permite, también, diferenciar entre diversos procesos de pago de un único donante: cuotas periódicas y donativos, dos apadrinamientos con distinto destinatario, donativos con destino diferente, etc.

- Pago: cada una de las acciones concretas en las que se materializa la aportación de recursos comprometidos en un compromiso de pago. En el caso de una donación puntual un compromiso de pago llevará asociado, normalmente, un único pago. En el caso de una cuota periódica, un compromiso de pago llevará asociados múltiples pagos. Así como los compromisos de pago manifiestan el compromiso, los pagos indican lo que realmente ha sucedido. Los pagos, pues, contienen los datos que serán utilizados para la elaboración de las remesas bancarias o el modelo 182 de Hacienda (en los casos en que procede su presentación).

Como se indicaba en los párrafos precedentes, los compromisos de pago y los pagos también pueden usarse para gestionar movimientos de salida (gastos) de la entidad. Por ejemplo, para pagar nóminas de empleados, servicios de colaboradores o subvenciones a usuarios de los programas, entre otras posibilidades.

Los módulos de Compromisos de pago y Pagos son particularmente sensibles a cambios realizados por el usuario en los diseños y otros elementos. Es recomendable, pues, tener cuidado al realizar modificaciones en estos módulos habida cuenta de que podría verse afectado su normal funcionamiento.


En cuanto a la generación de las remesas de domiciliación de recibos, cabe conocer también los siguientes conceptos:

- Cuenta bancaria: España está adherida al sistema IBAN (International Bank Account Number o, en español, Código Internacional de Cuenta Bancaria), por lo que los números de cuenta se denominan código IBAN o, simplemente, IBAN. La estructura del IBAN es diferente en cada país. En el caso de España, un IBAN es una cadena formada por 24 caracteres según la estructura siguiente: 2 caracteres alfabéticos para identificar el país (ES en el caso de España) + 2 digítos numéricos de control (del IBAN) + 4 dígitos numéricos para el código de la entidad bancaria + 4 dígitos numéricos para el código de la oficina + 2 dígitos numéricos de control (del antiguo Código Cuenta Cliente, el antecesor del IBAN) + 10 dígitos numéricos específicos como número de cuenta.

Cabe tener en cuenta que el CRM acepta y valida códigos IBAN de cualquier país, de modo que las entidades usuarias pueden, por ejemplo, emitir recibos domiciliados a sus socios y donantes residentes en otros países del área SEPA.

Mediante la constante GENERAL_IBAN_VALIDATION es posible activar o desactivar con carácter general la validación del IBAN en el campo Cuenta bancaria. Por defecto la constante toma el valor 1, que indica que el campoCuenta bancaria debe contener un IBAN válido. Este valor por defecto es el que deben utilizar todas las entidades que operan en el entorno SEPA (incluidas las españolas). Si se indica el valor 0 el campo Cuenta bancaria podrá contener cualquier dato. Este valor está indicado para aquellas entidades que operan fuera del entorno SEPA. Un vez establecido al valor apropiado, esta clave no debería cambiar.

- Mandato: es un código único que identifica la autorización que un socio o un donante ha hecho a una organización para que ésta le pueda realizar los cargos bancarios correspondientes en una cuenta determinada. Este código no tiene regla específica en cuanto a su estructura, más allá de garantizar que sea único para cada autorización. El campo Mandato se encuentra en el módulo de Compromisos de pago y es un campo de texto libre que cada organización puede rellenar según su propio esquema. De todos modos, y para facilitar su gestión, en el momento en que se crea un compromiso de pago, el CRM genera automáticamente un código de mandato, de modo que si la entidad no tiene ningún sistema establecido para su generación, puede utilizar este. En caso contrario, puede eliminarlo y sustituirlo por el código propio.

Cabe tener en cuenta que si se modifica la "Cuenta bancaria" de un compromiso de pago, el CRM generará automáticamente un nuevo mandato.


Alta de un compromiso de pago

Puede llevarse a cabo desde el subpanel correspondiente en el registro de persona u organización o bien desde el menú principal (Economía / Compromisos de Pago).


70.jpg


A continuación se describe brevemente el significado de los campos más relevantes:

- Nombre (del compromiso de pago): por razones de coherencia en la funcionalidad del CRM cada módulo de datos debe tener un campo Nombre. Así como en los módulos de Personas, Organizaciones, Proyectos, etc. este campo tiene sentido semántico pleno, en otros módulos (Compromisos de pago, Pagos, Relaciones con Personas, etc.) no lo tiene. En estos casos, la aplicación genera de forma automática estos nombres mediante la concatenación de valores de otros campos del registro creado, evitando al usuario el tener que pensar y aplicar una determinada nomenclatura. En cualquier caso, el usuario puede establecer, si así lo desea, su propio valor para el campo y el CRM lo respetará, omitiendo el automatismo mencionado.

- Persona / Organización: debe indicarse, de manera obligatoria, el nombre de la persona o de la organización (sólo uno de los dos) que realiza el compromiso de pago. De no cumplimentarse ninguno de los dos campos o en caso de cumplimentarse los dos, la aplicación lanzará el correspondiente mensaje de error.

- Destino: puede asociarse el compromiso de pago a la propia entidad (aportación genérica), a un proyecto, a una persona (por ejemplo, en el caso de apadrinamientos) o, incluso, a otra organización.

- Proyecto / Persona / Organización Destinatario: aquí se detalla el destinatario o beneficiario del compromiso de pago que se genera. Estos compromisos de pago aparecerán, consecuentemente, en el subpanel correspondiente de la ficha del proyecto, de la persona o de la organización destinataria.

- Tipo de pago: Cuota (socios, pagos recurrentes), Donativo (puntual o recurrente), En especie (con la posibilidad de incluir una valoración económica de la aportación), Servicios (de cualquier naturaleza) o Servicios agregados (para más información ver Pagos de servicios agregados). La lista de Tipos de pago puede adaptarse a las circunstancias particulares de la entidad sin afectar al funcionamiento del módulo.

- Medio de pago: Domiciliación, Tarjeta, Bizum, Paypal, Transferencia emitida, Transferencia recibida, Efectivo, Talón o En especie. Al elegir determinados medios de pago, el CRM puede mostrar u ocultar algunos campos de forma automática.

En el caso concreto de la Domiciliación, aparecen los campos Cuenta bancaria (por lo general, el IBAN) y Concepto del recibo. Vinculado al caso de las domiciliaciones también es relevante conocer de la existencia del campo Mandato (más información en el apartado Conceptos básicos).

- Periodicidad: Puntual (es decir, no periódica), Mensual, Bimestral, Trimestral, Semestral o Anual.

La lista desplegable asociada al campo Periodicidad no debería ser modificada por parte de la entidad, pues el CRM se basa en estos valores predeterminados para generar los futuros pagos recurrentes asociados a cada compromiso de pago periódico. En cualquier caso, las periodicidades disponibles deberían cubrir cualquier necesidad.

- Canal y campaña a través de los cuales se ha originado el compromiso de pago. No tiene efectos sobre la funcionalidad pero puede ser relevante a nivel de análisis sobre el valor aportado por los diferentes canales o campañas.

- Importe: en las cuotas periódicas, el importe de dicha cuota; en los donativos, el importe del donativo único; en los donativos en especie, la valoración económica de los mismos. En el caso de querer agrupar varios donativos puntuales de un mismo donante bajo un único compromiso de pago, el campo importe puede dejarse en blanco.

- Fecha de primer pago: aparece por defecto la fecha en que se da de alta el compromiso de pago, pero puede modificarse para coincidir con los criterios de la entidad o con el acuerdo al que se haya llegado con el socio/donante. Esta fecha se usará como Fecha de pago al crearse el pago inicial (ver Pago inicial).

- Tipo de transacción: Ingreso o Gasto. Permite caracterizar un compromiso de pago y sus pagos asociados a efectos de saber si se trata de una entrada o una salida de dinero. Puede servir para facilitar la inclusión de determinados pagos en una remesa o para la elaboración de informes, entre otras posibilidades.

- Concepto del recibo: texto que figurará en el recibo o la transferencia bancarios en el que se incluya el pago. Si se deja en blanco se usarán los valores indicados por defecto en los correspondientes parámetros.

Una parte importante de los datos asociados a un compromiso de pago son heredados por los pagos asociados al mismo (Importe, Cuenta bancaria, etc.). Algunos datos, sin embargo, no se traspasan (Destino y otros). Es importante tener en cuenta este hecho a fin de prever el impacto de los posibles cambios que un usuario pueda realizar en un compromiso de pago:

- De cambiar, por ejemplo, el Importe o la Cuenta bancaria de un compromiso de pago, los futuros pagos se adaptarían a los cambios realizados. El historial de pagos satisfechos hasta la fecha no se vería modificado en ningún caso.

- De modificarse el Destino –por ejemplo, cambiando la persona apadrinada–, tanto los pagos futuros como el histórico de pagos quedarían vinculados al nuevo destinatario, con lo que la información almacenada no se ajustaría completamente a la realidad de lo sucedido. Así pues, no es recomendable un cambio de esta naturaleza. En casos como este siempre será preferible dar de baja el compromiso de pago vigente y dar de alta uno nuevo con los nuevos datos.


Pago inicial y estado de los pagos

Tras la creación manual de cualquier compromiso de pago, sea cual sea el tipo, el medio de pago o la periodicidad de la misma, el CRM generará automáticamente uno o más pagos y los vinculará a dicho compromiso de pago, según las casuísticas siguientes:

- Siempre se creará un pago con Fecha de pago igual a la Fecha de primer pago indicada en el compromiso de pago.

- Si la Fecha de primer pago es anterior al mes actual, el CRM creará todos los pagos pertinentes (dependiendo de la periodicidad establecida) entre dicha fecha y el mes en curso.

- Si el valor de la constante GENERAL_PAYMENT_GENERATION_MONTH es 1 (ver Planificador y pagos recurrentes), se creará un pago para el mes siguiente al mes actual si la combinación de Periodicidad y Fecha de primer pago así lo requiere.

Los pagos creados recogerán las características descritas en el compromiso de pago de origen (Importe, Tipo de pago, Cuenta bancaria, Mandato, etc.) e incorporarán un estado en función del Medio de pago:

- Domiciliación / Tarjeta: el estado de los pagos generados es No remesado. En el caso de los pagos domiciliados, su estado se convertirá en Remesado en el momento en el que se genere la remesa correspondiente (ver Remesas de recibos domiciliados).

- Otros medios: el estado de los pagos generados es Pendiente. El usuario convertirá manualmente el estado a Pagado en el momento en el que se valide (por la vía que sea) que se han producido dichos pagos.

Los otros estados posibles de los pagos (Anulado, A recobrar, Impagado, Duplicado, Rechazado TPV) están relacionados con el ciclo de gestión de las remesas bancarias y/o de los pagos online y también pueden ser utilizados por parte de la entidad para la gestión manual de los procesos no automatizados.

En resumen:

- Los estados para los pagos cuyo medio de pago sea Domiciliación seguirán un ciclo semiautomático del tipo No remesadoRemesadoPagado. En caso de incidencia este último estado podrá ser sustituido por Anulado, A recobrar, Impagado o Duplicado.

- Los estados para los pagos únicos (o primeros pagos de una serie recurrente) efectuados mediante pasarela electrónica (TPV, PayPal) seguirán un ciclo automático del tipo PendientePagado. En caso de incidencia en un pago con tarjeta este último estado será sustituido por Rechazado TPV.

- Los estados para los pagos recurrentes cuyo medio de pago sea Tarjeta seguirán un ciclo semiautomático del tipo No remesadoPagado. En caso de incidencia este último estado será sustituido por Rechazado TPV.

- Los estados para otros pagos seguirán un ciclo del tipo PendientePagado (o Anulado o Impagado), siempre a partir de una gestión manual por parte de la entidad.


Compromisos de pago activos

De forma parecida a lo que sucede en los módulos Relaciones con Personas/Organizaciones, también en Compromisos de Pago resulta de utilidad saber si un compromiso con periodicidad no puntual es activo o no, es decir, si va a seguir generando pagos futuros con la periodicidad establecida. Para un registro dado esto se va a cumplir si el compromiso no tiene fecha de baja o la fecha es futura. Sin embargo, filtrar el conjunto de compromisos para obtener esta información puede suponer, por ejemplo, la creación de condiciones de filtrado complejas en el marco de un informe.

Para facilitar este tipo de operaciones el módulo Compromisos de pago cuenta con un campo llamado Activo, que el CRM gestiona de forma automática. En cada edición de cualquier registro y también mediante una tarea programada de ejecución diaria el CRM determina si el registro en cuestión es un compromiso activo o inactivo y marca o desmarca este campo según lo que proceda. Disponiendo de este campo, localizar o filtrar compromisos de pago activos o inactivos se convierte en algo tan simple como establecer una condición de filtrado sobre este campo.

A pesar de que el CRM aplica esta operación sobre todos los compromisos de pago existentes, cabe tener en cuenta que para los puntuales el contenido del campo no tendrá un valor que por lo general resulte significativo, pues en principio un compromiso de pago puntual solo puede considerarse activo en el momento en el que se genere o cobre el pago asociado, pero no a lo largo del tiempo.


Pagos realizados por una persona/organización en beneficio de otra

En determinadas situaciones las personas/organizaciones que realizan un pago no son las mismas que se acaban beneficiando de lo que comporta ese pago.

Por ejemplo, en el ámbito de la infancia, los adultos realizan el pago de una actividad en la que participa un menor. O en el caso de los ámbitos de la discapacidad o de las personas mayores las personas tutoras realizan pagos en nombre de los usuarios. También una persona puede pagar la cuota de socio de cualquier entidad en beneficio de un amigo o familiar. En otros casos las personas realizan donativos para su apadrinado o para un proyecto en particular.

En las situaciones de esta naturaleza es habitual que se desee tener constancia de ese doble vínculo entre el compromiso de pago y las personas/organizaciones que realizarán los pagos y las personas/organizaciones que se beneficiarán del efecto de esos pagos.

A este fin, en el módulo Compromisos de pago existen los campos Persona destinataria, Organización destinataria o Proyecto destinatario, que permiten indicar que la persona/organización pagadora (es decir, la indicada en el campo Persona u Organización) realizará el pago en nombre o en beneficio de la persona, organización o proyecto indicados como destinatarios.


PagosDelegados.png


Rellenar estos campos también implica que la información del compromiso de pago se visualizará no solo en la persona/organización que realiza el pago sino también en la persona, la organización o el proyecto destinatarios.

En el caso de los pagadores, los compromisos de pago aparecen en el subpanel Compromisos de pago.


CdP persona pagadora.png


En el caso de los destinatarios, en el subpanel Compromisos de pago en los que la persona/organización es la destinataria.


CdP persona destinataria.png

Planificador y pagos recurrentes

Para los compromisos de pago periódicos SinergiaCRM genera automáticamente los pagos recurrentes correspondientes a partir de la periodicidad establecida en cada caso (mensual, bimestral, trimestral, etc.). Dichos pagos se procesarán posteriormente de forma manual (caso de pagos en efectivo, por transferencia, talón, en especie, etc.) o automática (caso de remesas de recibos domiciliados o de pago con tarjeta).

El proceso de generación automática de pagos recurrentes se gestiona mediante una tarea programada, accesible y configurable en Administración / Sistema / Planificador.


71.jpg


Se puede elegir generar los pagos para el mes en curso, que se suele ser lo habitual, o para el mes siguiente al mes en curso, de forma que, por ejemplo, se pueda preparar una remesa bancaria sin esperar al cambio de mes. El control de la generación de los pagos recurrentes se realiza mediante la constante llamada GENERAL_PAYMENT_GENERATION_MONTH. Si el valor de la constante es 0 (valor por defecto), la generación de los pagos recurrentes se llevará a cabo para el mes en curso. Si el valor de la constante es 1, se crearán los pagos para el mes siguiente.

Se recomienda elegir una de las dos modalidades (mes actual / mes siguiente) y permanecer en ella. Cambiar el modo de trabajo sin entender los efectos de dicho cambio podría provocar, por ejemplo, la no creación de pagos en un determinado mes.

Por defecto el proceso de generación de los pagos recurrentes se lleva a cabo cada primero de mes a las 00:30h. La entidad puede modificar los parámetros de ejecución para, por ejemplo, provocar que la generación de pagos se efectúe en otra fecha que no sea el día 1 del mes.

El sistema creará un pago para un determinado compromiso de pago si este se encuentra activo (es decir, sin Fecha de baja o con Fecha de baja futura), tiene una periodicidad establecida (no es Puntual) y el mes para el que se crean los pagos coincide con Fecha de primer pago + Periodicidad. Por ejemplo, para un compromiso de pago trimestral con fecha de primer pago en enero se generarán pagos en los meses de abril, julio, octubre, enero siguiente, etc.

El sistema no generará un nuevo pago para un compromiso de pago si detecta que para el mes para el que se están generando los pagos ya existe un pago vinculado a ese compromiso de pago.

El estado de los pagos recurrentes generados será, en función del medio de pago:

- Domiciliación / Tarjeta: el estado de los pagos generados es No remesado. En el caso de los pagos domiciliados, su estado se convertirá en Remesado en el momento en el que se genere la remesa correspondiente (ver Remesas de recibos domiciliados).

- Otros medios: el estado de los pagos generados es Pendiente. El usuario convertirá manualmente el estado a Pagado en el momento en el que se valide (por la vía que sea) que se han producido dichos pagos.

El límite para la generación de pagos recurrentes es el indicado por la Fecha de baja en el compromiso de pago correspondiente: si la Fecha de baja existe y es anterior a la de la ejecución del proceso cesa la generación de nuevos pagos. Puede así gestionarse, si la entidad lo desea, una fecha límite para los compromisos de pago.


Anticipar puntualmente la generación de pagos recurrentes

En determinadas circunstancias (ante un periodo vacacional, etc.) una entidad que habitualmente trabaja en modo "mes en curso" (GENERAL_PAYMENT_GENERATION_MONTH = 0) puede querer anticipar la generación de los pagos del mes siguiente. Lograr este objetivo es posible, pero es importante entender bien los pasos a realizar para evitar que se produzca cualquier incidencia:

1) Esperar hasta que se hayan generado los pagos del mes en curso. Por defecto los pagos recurrentes se generan el día 1 pero la entidad puede haber modificado esta fecha a conveniencia. En cualquier caso, antes de anticipar los pagos del mes siguiente cabe asegurarse que los del mes en curso ya han sido creados para que no quede un mes sin pagos generados.

2) Cambiar a 1 el parámetro GENERAL_PAYMENT_GENERATION_MONTH.

3) Modificar la tarea programada de generación de pagos recurrentes y asignarle el día apropiado (cualquiera entre la fecha actual y el último día del mes, según convenga).

4) Al llegar el día indicado, comprobar que se han generado los pagos del mes siguiente como consecuencia de haber puesto a 1 el parámetro GENERAL_PAYMENT_GENERATION_MONTH.

5) Restablecer la fecha original en la tarea programada y devolver a valor 0 el parámetro GENERAL_PAYMENT_GENERATION_MONTH.

6) En el mes siguiente no se generarán pagos puesto que ya habrán sido generados en el mes actual (salvo que por el camino aparezcan compromisos de pago que lo requieran por cualquiera de las razones habituales). En los meses sucesivos la creación volverá a su ciclo normal.


Remesas bancarias

Remesas de recibos domiciliados

Una remesa de recibos domiciliados es un conjunto de pagos del CRM que se transfieren a una entidad financiera para que esta los cobre a favor de la entidad en las cuentas de los correspondientes socios y donantes. El proceso de domiciliación bancaria ha estado regido en España históricamente por la normativa N19 – Adeudo por domiciliaciones en soporte magnético y actualmente, por la normativa europea SEPA (Single Euro Payments Area) que afecta a diferentes medios de pago, entre los cuales los adeudos domiciliados o recibos.

En el momento en el que la organización pretenda generar una remesa de recibos (por ejemplo, una remesa mensual), debe, en primer lugar, crearse la remesa como tal en el módulo correspondiente. Para una remesa puede detallarse Nombre, Estado (Abierta, Generada o Enviada), Tipo (en este caso Domiciliaciones), Fecha de cargo de los recibos y Cuenta bancaria (número de cuenta donde depositar el dinero obtenido mediante el cobro de los recibos).


1001.jpg


Una vez guardada la remesa se mostrará su vista de detalle, en la que aparecerá el subpanel Pagos, a través del cual podrán seleccionarse los pagos a incorporar a la remesa. El criterio habitual de selección será del tipo pagos con estado "No remesado" y tipo "Domiciliación" aunque podrán establecerse otros criterios cuando sea necesario (según fecha, etc.).


98.JPG


Existe una forma alternativa de cargar los pagos en una remesa que es particularmente recomendable en el caso de que el número de pagos a cargar sea elevado. En la vista de lista de Pagos se seleccionan los registros a cargar y desde el botón-menú de acciones se elige la opción Añadir a remesa.


PagosRemesas.jpg


A continuación aparecerá la vista emergente de Remesas, en la que podrá elegirse la remesa deseada. Seleccionada la remesa, se mostrará su vista de detalle, en la que aparecerán los pagos asignados en el subpanel habitual. Tal y como se ha indicado, este método se ejecuta de forma más rápida y se recomienda en caso de remesas voluminosas.

Tras la creación de la remesa y la asignación de los pagos a incluir en ella podrá generarse el correspondiente fichero en formato SEPA (XML) desde el menú del botón de acciones de la remesa. El resultado de la operación es la descarga del fichero que deberá entregarse a la entidad financiera.


1002.jpg


Al generar la remesa, el CRM analizará tanto los datos generales de la propia remesa como los datos particulares de los pagos asociados a ella. En caso de encontrar errores los mostrará en pantalla. Los errores pueden ser de carácter bloqueante, es decir, que deberán ser subsanados antes de poder generar un fichero correcto, o no bloqueantes, que podrán ser subsanados, si procede, después de haber generado el fichero. En caso de que existan errores bloqueantes el fichero no se generará.

Para que el formato del fichero SEPA sea adecuado a la normativa y, por lo tanto, aceptado por la entidad financiera, deben haberse cumplimentado previamente los datos de configuración general a través del módulo Configuración. En apartados posteriores se describen los parámetros concretos que afectan al proceso de generación de remesas.

No debe eliminarse ningún registro del módulo de Configuración relacionado con SEPA, pues podría verse afectada su correcta generación.

Una vez generado el fichero SEPA, la remesa pasa del estado inicial Abierta a Generada. Los pagos asociados a dicha remesa cambian su estado a Remesado.

El envío a la entidad financiera del fichero descargado lo realizará cada organización según su procedimiento habitual. A continuación deberá cambiarse manualmente el estado de la remesa a Enviada. Al hacerlo todos los pagos asociados a esa remesa pasarán al estado Pagado, a la espera de posibles devoluciones.

Que los pagos queden en estado Pagado es importante, por ejemplo, para la generación del Modelo 182, razón por la cual conviene adquirir el hábito de marcar las remesas como enviadas cuando sea el caso.
No se deben modificar los valores de las listas desplegables de los campos Estado en los módulos de Remesas y Pagos, ya que, como se acaba de indicar, influyen en el proceso de generación de los ficheros SEPA.


Remesas de transferencias

Una remesa de transferencias es parecida a una remesa de recibos domiciliados, con la diferencia de que el objetivo de la misma es emitir un conjunto de pagos en lugar de cobrarlos.

Así, el procedimiento para generar una remesa de transferencias es similar al utilizado para domiciliaciones. Cabe tener presente que en el campo Tipo deberá indicarse el valor Transferencias emitidas.


Tipo remesa.png


Para gestionar las remesas de transferencias es necesario rellenar dos parámetros específicos para este fin (Ver Parámetros SEPA para remesas de transferencias).


Parámetros SEPA para remesas de recibos domiciliados

- GENERAL_ORGANIZATION_NAME: El nombre de la entidad usuaria del CRM.

- SEPA_DEBIT_DEFAULT_REMITTANCE_INFO: El concepto por defecto del recibo. El concepto del compromiso de pago tiene prioridad sobre el valor del parámetro general, pero conviene establecer el valor de este parámetro para evitar que un compromiso de pago sin concepto genere un recibo sin concepto.

- SEPA_DEBIT_CREDITOR_IDENTIFIER: Es el código de identificación del acreedor (es decir, de vuestra entidad). Su estructura es ESZZXXXAAAAAAAAA, donde: ES: código de país / ZZ: dígitos de control / XXX: sufijo (normalmente 000) / AAAAAAAAA: NIF del acreedor (es decir, el NIF de la entidad usuaria del CRM) Es posible hacer el cálculo de los dígitos de control en este enlace.

Aparte de los tres parámetros indicados existen otros dos que en algunos casos pueden ser relevantes: SEPA_BIC_MODE y SEPA_BIC_CODE. BIC significa Bank Identifier Code o Código de Identificación Bancaria (también se le conoce como código SWIFT). El BIC dejó de ser obligatorio a todos los efectos en 2016 (http://www.sepaesp.es/sepa/es/faqs/sepa/), por lo que este parámetro dejó de utilizarse en el proceso de generación de remesas. Sin embargo, se ha detectado que alguna entidad financiera (particularmente, el Santander) todavía lo exige.

A fin de evitar que estas entidades financieras que no han adaptado su software rechacen las remesas generadas por el CRM se ha habilitado el parámetro SEPA_BIC_MODE. Por defecto, su valor es 0, que indica que no se usa el BIC en las remesas. Las entidades que necesiten usar el BIC pueden establecer a 1 el valor de este parámetro y en este caso se incorporará a la remesa el valor indicado en SEPA_BIC_CODE, tal y como se hacía antiguamente. Este último dato puede encontrarse en la correspondiente aplicación de banca online. También puede obtenerse en este enlace a partir del número de cuenta IBAN.

Cabe tener en cuenta que actualmente es posible disponer de varios números de cuenta a incorporar en una remesa (ver Operativa multicuenta/multibanco) mientras que solo existe un parámetro para el BIC, por lo que debe tomarse la precaución de asegurar que SEPA_BIC_MODE solo se activa para generar remesas asociadas a un IBAN de la entidad financiera a la que corresponde el BIC indicado. De lo contrario, la remesa contendría un IBAN y un BIC incompatibles y el banco rechazaría el fichero.


Parámetros SEPA para remesas de transferencias

- GENERAL_ORGANIZATION_NAME: El nombre de la entidad usuaria del CRM.

- SEPA_TRANSFER_DEFAULT_REMITTANCE_INFO: Concepto que figurará en la orden de pago en caso de que no se especifique en el mismo registro del pago.

- SEPA_TRANSFER_DEBITOR_IDENTIFIER: Identificador SEPA de la entidad. Ver SEPA_DEBIT_CREDITOR_IDENTIFIER en el apartado anterior.


Operativa multicuenta/multibanco

Históricamente el CRM operaba con un único número de cuenta para las remesas bancarias, configurado en el módulo Configuración. Actualmente es posible indicar de manera individual en cada remesa el IBAN de la cuenta vinculada a la remesa, lo que permite trabajar con diferentes cuentas bancarias de una o más entidades financieras. Para ello es necesario que previamente se registren los IBANs que se quieran utilizar. Esto puede hacerse en Administración / Editor de Listas Desplegables / stic_remittances_ibans_list.


Selección 124.png


El proceso de incorporación de IBAN a la lista es el siguiente:

1. Indicar en la casilla Nombre del Elemento el IBAN de la cuenta bancaria. En el caso español tendrá un formato del tipo ES0000000000000000000000, donde los 0 indican cualquier dígito numérico.

2. Indicar en la casilla Etiqueta de Visualización el nombre con el que identificaremos la cuenta. El formato es libre pero se recomienda seguir un patrón: Nombre de la entidad financiera + Últimas cuatro cifras de la cuenta o cualquier otra denominación que permita reconocer y diferenciar los diferentes números de cuenta.

3. Agregar el elemento y pulsar en Guardar. En este momento ya lo tendremos disponible en la vista de edición de la remesa.


Multibanco.png


Errores y avisos en la generación de ficheros

Al intentar generar un fichero SEPA de domiciliaciones o transferencias, el CRM analizará la consistencia de los propios datos de la remesa y de los pagos incluidos.

En caso de que al generar el fichero se encuentre algún dato que impida que la remesa se genere correctamente, se mostrará un mensaje en pantalla avisando del error y no se generará el fichero.


Avisobloq.png


En caso de que no se encuentren problemas del tipo anterior pero sí se detecten incoherencias en los datos relativos a los pagos incluidos, se generará el fichero y se incluirá en la vista de detalle de la remesa la información relativa a los problemas detectados, para facilitar su corrección. La entidad deberá valorar la necesidad de volver a generar o no la remesa en función de las correcciones efectuadas.


Logsremesa.png


Una vez generado el fichero, para poder observar el texto con los problemas detectados puede ser necesario recargar (F5) la vista de detalle de la remesa.


Gestión de devoluciones de remesas bancarias

Tras el envío de una remesa de recibos domiciliados, la entidad financiera puede devolver a la organización uno o varios ficheros de incidencias, asignando a cada pago no realizado un código de incidencia estandarizado.

Mediante el siguiente proceso podrán gestionarse dichos ficheros a fin de marcar automáticamente en el CRM los pagos que no han podido efectuarse:

- En el menú de acciones del módulo de Remesas aparece las opción de Cargar Devoluciones.


76.jpg


- Se mostrará entonces la siguiente ventana emergente para poder seleccionar el fichero de devoluciones:


77.jpg


- Una vez seleccionado el fichero y pulsado el texto Cargar, el sistema verificará que está bien formado y que sus datos se corresponden con los definidos en el sistema. Si el fichero no es correcto el sistema mostrará el correspondiente mensaje de error. Si el fichero es correcto, el sistema procederá a marcar los pagos del fichero con el estado Impagado (recordemos que todos tenían estado Pagado desde el momento en que se marcó la remesa como Enviada) y a indicar el motivo de devolución detallado por el banco.

Tras la carga y actualización de los pagos devueltos, la entidad podrá decidir la estrategia a seguir con los registros implicados: contacto telefónico, nuevo intento de domiciliación, etc. En caso de nueva domiciliación el proceso será similar al planteado en la creación de la remesa inicial, seleccionando los registros correspondientes a las devoluciones y con el resto de parámetros adecuados.

Remesas de pagos con tarjeta

Las pasarelas de pago online suelen permitir, de una u otra forma, la posibilidad de gestionar pagos con recurrencia, de modo que si el titular del medio de pago ha dado su autorización, se pueden emitir pagos sin intervención explícita del pagador. A efectos prácticos, el CRM propone gestionar este tipo de pagos mediante remesas, de una forma parecida a cómo se gestionan las domiciliaciones o las transferencias bancarias, a fin de que para los usuarios la operativa resulte familiar en todo momento.

Así pues, una remesa de pagos con tarjeta es un conjunto de pagos del CRM que se agrupan para posteriormente ser cobrados mediante un proceso en el que el CRM lanzará de forma automática los pagos contra el TPV y este de forma síncrona irá informando al CRM del resultado de cada pago. En este sentido, y a diferencia de los otros tipos de remesa, no será necesario descargar ningún fichero sino que CRM y TPV se comunicarán directamente de forma transparente para el usuario, tal y como sucede cuando se tramitan pagos con tarjeta en formularios web.

Así, el procedimiento para construir una remesa de pagos con tarjeta es similar al utilizado para domiciliaciones. Cabe tener presente que en el campo Tipo deberá indicarse el valor Tarjetas.

Una vez incorporados a la remesa los pagos a cobrar, para hacerlos efectivos bastará con lanzar la acción Procesar pagos con tarjeta en el botón menú de acciones de la vista de detalle de la remesa.

Al lanzar el proceso el CRM analizará los datos generales de la remesa. En caso de encontrar un error bloqueante el proceso se interrumpirá y el error deberá ser subsanado antes de poder relanzarlo. En caso de que no exista ningún error de este tipo el CRM lanzará los pagos uno por uno contra el TPV y actualizará su estado, que pasará a Pagado si la operación de cobro ha sido exitosa o a Rechazado TPV en caso contrario.

Al finalizar la ejecución de todos los pagos incluidos en la remesa el CRM mostrará en pantalla el resultado global junto a un listado de los posibles errores producidos en los pagos individuales. El usuario podrá decidir excluir de la remesa los pagos con error, tratar de subsanarlos o, simplemente, proceder a intentar el recobro en una nueva ejecución del proceso. En este sentido cabe tener en cuenta que el CRM no intentará recobrar pagos que ya se encuentren en estado Pagado.

En el caso especial de que un pago no haya podido ser cobrado por caducidad de la tarjeta el CRM rellenará la fecha de baja del compromiso de pago asociado (a fin de evitar la futura generación de pagos que no podrían ser cobrados) y enviará un correo de notificación al usuario asignado a dicho compromiso de pago.

Como en el resto de remesas, se recomienda modificar su estado a Enviada una vez todos los pagos hayan sido cobrados o excluidos de la remesa. A diferencia de los otros tipos de remesa, el hecho de marcar una remesa de pagos con tarjeta como enviada no provocará un cambio masivo del estado de los pagos incluidos en ella puesto que el estado de cada pago se gestiona de forma individual durante el proceso, tal y como ya se ha explicado.

Finalmente, cabe tener en cuenta que para procesar remesas de pagos con tarjetas no es necesario realizar ninguna configuración especial en el CRM más allá de la que ya se debe hacer para poder operar con el TPV de Redsys en el marco de los formularios web.


Consideraciones adicionales sobre pagos recurrentes con tarjeta/PayPal

Incorporación de los campos al interfaz

En la funcionalidad de pagos recurrentes con tarjeta/PayPal se utilizan determinados campos que por defecto no se muestran en las vistas de los módulos a los que pertenecen por no ser de uso generalizado. En aquellas instancias en las que se desee visualizar estos campos será necesario intervenir explícitamente sobre las correspondientes vistas para incorporarlos. Los módulos y campos son los siguientes:

- Compromisos de pago: Referencia para pagos recurrentes en TPV (redsys_ds_merchant_identifier), Identificador de transacción COF (redsys_ds_merchant_cof_txnid), Fecha de caducidad de la tarjeta (card_expiry_date), Referencia para pagos recurrentes en PayPal (paypal_subscr_id) y Registro de la pasarela (gateway_log).

- Pagos: Registro de la pasarela (gateway_log).

Todos estos campos son únicamente de lectura y el CRM introduce en ellos información recibida de las pasarelas de pago durante cualquier operación, sea de autorización inicial, sea de cobro recurrente posterior. Aunque en la operativa cotidiana estos campos pueden no ser de especial interés, en caso de incidencias con los pagos la información que aparezca en ellos puede ayudar a determinar su causa y/o su resolución.


Cobro de pagos periódicos en PayPal

Dado que PayPal se encarga proactivamente de cobrar sus recurrencias, no es necesario gestionar remesas para este tipo de pagos (a diferencia del caso de los pagos con tarjeta). Cada vez que PayPal ejecute con éxito una operación de cobro, enviará al CRM una notificación con la información correspondiente. El CRM buscará el pago al que corresponde la notificación (que ya se habrá creado en el CRM como cualquier otro pago recurrente) y lo marcará como pagado.


Baja de compromisos de pago en PayPal

Si en algún momento un donante (o la propia entidad receptora) cancela una suscripción en PayPal, la pasarela lo notificará al CRM, quien localizará el compromiso de pago correspondiente, le asignará fecha de baja (con lo que ya no se generarán nuevos pagos) y enviará también una notificación al usuario asignado al pago.

Cabe tener en cuenta que establecer manualmente una fecha de baja en el compromiso de pago en el CRM no supone el envío de instrucción alguna a PayPal, por lo que esta pasarela seguirá ejecutando cobros con la periodicidad prevista. La forma correcta de cancelar una suscripción a todos los efectos es iniciar el proceso en PayPal, lo que, como se ha indicado, provocará también su baja en el CRM.


FAQS en torno al bloque de módulos de Economía

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 y en los artículos Modelo 182 y Subvenciones. Algunos aspectos que aparecen en el vídeo podrían haber evolucionado con posterioridad a su edición.


Volver al índice