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 necesidadesmá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 recurrentes (cuotas de socios o donaciones periódicas), se lleva a cabo desde un enfoque a dos niveles:

- Compromiso de pago: es el compromiso que adquiere un socio/donante 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.

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.

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 En especie (con la posibilidad de incluir una valoración económica de la aportación). 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, 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 a la misma (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 el 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 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: el estado de los pagos generados es No remesado. Se convertirán 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 desde la entidad se valide 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 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 cuyo medio de pago sea diferente de Domiciliación seguirán un ciclo del tipo PendientePagado (o Anulado o Impagado), siempre a partir de una gestión manual por parte de la entidad.


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

El proceso de generación automática de pagos recurrentes se gestiona mediante una tarea programada, accesible y configurable desde 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á pagos para un compromiso de pago con Fecha de primer pago en el mes en curso pues se supone que en este caso el pago ya se ha creado automáticamente al crear el compromiso de pago (ver Pago inicial). Tampoco lo hará si detecta que para el mes en curso ya existe un pago vinculado a este compromiso de pago.

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

- Domiciliación: el estado de los pagos generados es No remesado. Se convertirán 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 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.


Remesas

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 ésta 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 cargar la remesa).

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" aunque podrán establecerse otros criterios cuando sea necesario.

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

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.


Modelo 182

Durante el mes de enero las entidades sin ánimo de lucro deben preparar el Modelo 182. Declaración Informativa. Donativos, donaciones y aportaciones recibidas y presentarlo a la Agencia Tributaria. Este modelo presenta un resumen de las donaciones recibidas durante el año natural anterior.


Generación del 182

Desde el menú de acciones del módulo de Pagos puede lanzarse el proceso de generación del modelo.

M182 menu.jpg

En la pantalla mostrada la entidad podrá elegir qué tipos de pagos deben ser incluidos en el modelo 182. Esto permite incluir o excluir a voluntad tipos de pago propios que la entidad pueda haber creado para gestionar sus necesidades concretas. Debe elegirse por lo menos un tipo de pago y, a continuación, pulsar en el botón Generar M182.

M182 asistente.jpg

El CRM incluirá en el modelo 182 todos los pagos en estado Pagado y con fecha correspondiente al año anterior al que se esté ejecutando el proceso. Además, según la normativa actualmente vigente, tendrá en cuenta los pagos análogos de los dos ejercicios precedentes para determinar qué donantes pueden ser considerados recurrentes y disponer de una deducción fiscal mayor.

Tal y como ocurre con las remesas SEPA, una vez terminado el proceso se descargará el fichero correspondiente y la organización podrá gestionarlo ante la Agencia Tributaria según su protocolo habitual.

Cabe tener en cuenta que el CRM puede no haber incorporado al fichero aquellos donantes cuyos datos no estén completos y/o contengan errores. La entidad deberá revisar estos registros antes de proceder al envío del fichero para asegurarse de que el fichero contiene todos los datos necesarios (ver más adelante en este mismo apartado).

Como parte del proceso de generación del fichero del Modelo 182, el sistema actualiza el campo Total donación anual para cada registro de persona u organización afectado. Este campo puede ser utilizado para la elaboración de los certificados de donaciones.


Nombre fiscal

En el ejercicio 2017 la Agencia Tributaria introdujo un cambio en la gestión del Modelo 182, obligando a las entidades a notificar los nombres de socios y donantes tal y como figuran en la base de datos de la propia Agencia Tributaria. Es decir, si el nombre suministrado por la entidad (por ejemplo, Pepe García) no coincide con el que la Agencia Tributaria maneja (por ejemplo, José María García), el fichero será rechazado indicándose un error en el registro aun cuando el NIF suministrado sea correcto. Para evitar perder en el CRM el nombre con el que la persona donante quiere ser atendida o identificada, se dispone en el módulo Personas del campo Nombre fiscal, en el que se puede indicar el nombre completo (nombre y apellidos) que la Agencia Tributaria espera recibir. En el momento de generar el Modelo 182 el CRM priorizará el contenido de este campo sobre los habitualesNombreyApellidos, que se usarán cuando el campoNombre fiscalesté vacío. El campo Nombre fiscalestá disponible también en el módulo Organizaciones.

Más información sobre este aspecto en el sitio web de la Agencia Tributaria.

Servicio de comprobación de nombres y NIF de la Agencia Tributaria.


Exclusión de donantes o pagos

Si una organización necesita que determinados pagos o donantes no sean tenidos en cuenta en este proceso puede marcar el campo Excluir del modelo 182 en cualquier registro de estos tres módulos: Pagos, Personas u Organizaciones. Al activar la marca en un registro de los módulos Personas u Organizaciones, todos los pagos de esa persona u organización serán excluidos del Modelo 182 con independencia de si la marca está presente o no en cada uno de los pagos. Si la marca no se aplica al donante sino solo a algunos de sus pagos serán solamente esos pagos los que no serán incluidos, pero sí el resto de pagos de ese donante.

Es importante tener presente que para generar correctamente el fichero y evitar errores al cargarlo en los sistemas de la Agencia Tributaria todos los donantes (personas u organizaciones) deben tener el NIF y la provincia principal correctamente indicados además de su nombre y/o apellidos. La única excepción es el caso de contribuyentes no residentes en España, en cuyo caso deberán tener indicado el valor No residente en el campo Provincia y podrán tener cualquier valor (incluso en blanco) en el campo Número de identificación.


Registros con errores

En caso de que durante el proceso de generación del Modelo 182 el CRM encuentre registros que no tengan los datos que la Agencia Tributaria requiere (nombre, apellidos, NIF, provincia) los excluirá del fichero final y activará el campo Error modelo 182 en cada uno de ellos. Así pues, una vez descargado el fichero la entidad debería verificar en el CRM que no existen ni personas ni organizaciones a las que se haya activado este campo. Para ello bastará con realizar una búsqueda en cada uno de estos dós módulos indicando como filtro el valor para el campo mencionado. En caso de aparecer registros erróneos, la entidad deberá analizarlos uno por uno y corregirlos o marcarlos como excluidos del 182, según se ha descrito anteriormente. Hecho esto podrá generar nuevamente el fichero para incorporar a los donantes revisados. El fichero podrá considerarse definitivo cuando tras su generación no aparezcan ya registros marcados como erróneos ni en Personas ni en Organizaciones.

Taly como se ha explicado anteriormente, la Agencia Tributaria realiza un control por el que se verifica que el nombre del donante y su NIF coincidan con los datos que obran en su poder. En caso de que el nombre del donante en el CRM sea significativamente diferente del que consta en su NIF es posible que al cargar al mandar el fichero a la Agencia Tributaria aparezcan errores del tipo Declarado no identificado. En estos casos podría ser necesario contactar con el donante para verificar sus datos (ver el apartado anterior Nombre fiscal).


Envío de certificados

Aunque actualmente SinergiaCRM no cuenta con un mecanismo que permita generar automáticamente un documento en formato PDF con el certificado y enviarlo por correo electrónico a cada uno de los donantes, sí es posible conseguir el objetivo final por dos vías diferentes: mediante una campaña de correo electrónico, que es la opción recomendada, o bien en papel, generando los documentos mediante Mail Merge Reports.


Campaña de correo electrónico

Nota: En caso de que la entidad no haya realizado anteriormente ninguna campaña de envío de correo electrónico desde el CRM, se recomienda la lectura del artículo Campañas.

1) Generar una plantilla HTML con el texto del certificado e incluir en ella los datos a personalizar para cada donante: nombre, apellidos, NIF, dirección, importe total donado, etc.

2) Crear una lista de público objetivo con las personas a las que se desea enviar el certificado. Se recomienda crear también una lista de pruebas.

3) Crear una campaña y un correo de marketing utilizando la plantilla de correo y las listas creadas en los pasos anteriores.

4) Realizar un envío de prueba y verificar los correos recibidos (repetir este paso tantas veces como sea necesario hasta obtener el resultado deseado).

5) Realizar el envío de la campaña.

Si se desea enviar el certificado también a las organizaciones donantes, será necesario repetir los pasos anteriores adaptados al caso.


Envío en papel

Nota: Si la entidad no está habituada al uso de las plantillas de documentos se recomienda la lectura del artículo Mail Merge Reports - Combinar correspondencia.

1) Crear una plantilla de Mail Merge Reports basada en el módulo Personas con el texto del certificado y el formato de documento deseado. En el apartado correspondiente del wiki hay disponible una plantilla de ejemplo.

2) Seleccionar las personas a las que se desea enviar el certificado en el buscador del módulo Personas y pulsar la opción Generar documento.

3) Entre las plantillas disponibles en el módulo, escoger la creada anteriormente.

4) Descargar el documento e imprimirlo.

5) Separar los certificados y enviarlos por correo postal

Una vez creada la plantilla también es posible generar el certificado persona a persona, en este caso accediendo a la ficha de la misma y seleccionando la opción Generar documento.

182 generar document individual.png

Si se desea enviar el certificado también a las organizaciones donantes, será necesario repetir los pasos anteriores adaptados al caso.


Parámetros del Modelo 182

Antes de generar el Modelo 182 es necesario configurar adecuadamente los parámetros relacionados con este modelo en el módulo de Configuración:

- GENERAL_ORGANIZATION_NAME: El nombre de la entidad (máximo 40 caracteres).

- GENERAL_ORGANIZATION_ID: El NIF de la entidad.

- M182_NATURALEZA_DECLARANTE: 1, 2, 3 o 4, según proceda (normalmente 1 o 2, ver más información en las Notas adicionales)

- M182_CLAVE_DONATIVO: A, B, C, D, E o F, según proceda (normalmente A, ver más información en las Notas adicionales)

- M182_JUSTIFICANTE: Código único de la declaración que se puede obtener en el sitio web de la Agencia Tributaria a través del siguiente enlace: https://www2.agenciatributaria.gob.es/L/inwinvoc/es.aeat.adht.nume.web.editran.NumRefEditran?mod=182. El valor generado debe ser trasladado al CRM sin espacios, sólo los 13 dígitos numéricos.

- M182_PORCENTAJE_DEDUCCION_AUTONOMICA_XX: (ver más información en las Notas adicionales)

- M182_PERSONA_CONTACTO_APELLIDO_1: Primer apellido de la persona de contacto.

- M182_PERSONA_CONTACTO_APELLIDO_2: Segundo apellido de la persona de contacto.

- M182_PERSONA_CONTACTO_NOMBRE: Nombre de la persona de contacto.

- M182_PERSONA_CONTACTO_TELEFONO: Teléfono de contacto.

En una versión anterior de SinergiaCRM aparecían también parámetros relativos a los diferentes porcentajes de deducción existentes (personas físicas / jurídicas, recurrentes / no recurrentes, etc.). Al ser datos fijos que no dependen de cada entidad han sido eliminados del módulo Configuración e introducidos directamente en el código del CRM (ver más información en este artículo específico sobre cambios entre las versiones del CRM).


Notas adicionales sobre los parámetros del Modelo 182

Clave del donativo

Este valor es individual para cada donación recibida pero el CRM asume que el valor es único para cada organización.

Deberá rellenarse por las entidades acogidas al régimen de deducciones establecido en el Título III de la Ley 49/2002, de 23 de diciembre, según el siguiente detalle:

- A Donativos NO incluidos en las actividades o programas prioritarios de mecenazgo establecidos por la Ley de Presupuestos Generales del Estado.

- B Donativos incluidos en las actividades o programas prioritarios de mecenazgo establecidos por la Ley de Presupuestos Generales del Estado.

Tratándose de aportaciones o disposiciones a patrimonios protegidos deberá detallarse alguna de las siguientes claves:

- C Aportación al patrimonio de discapacitados.

- D Disposición del patrimonio de discapacitados.

- E Gasto de dinero y consumo de bienes fungibles aportados al patrimonio protegido en el año natural al que se refiere la declaración informativa o en los cuatro anteriores para atender las necesidades vitales del beneficiario y que no deban considerarse como disposición de bienes o derechos a efectos de lo dispuesto en el artículo 54.5 de la Ley 35/2006, de 28 de noviembre, del Impuesto sobre la Renta de las Personas Físicas.

Los Partidos Políticos, Federaciones, Coaliciones o Agrupaciones de Electores consignarán las siguientes claves:

- F Cuotas de afiliación y aportaciones previstas en el artículo 2.Dos.a) de la Ley Orgánica 8/2007, de 4 de julio, sobre financiación de los partidos políticos.

- G Resto de donaciones y aportaciones percibidas.

Naturaleza del declarante

Se hará constar el dígito numérico indicativo de la naturaleza del declarante, de acuerdo con la siguiente relación:

- 1 Entidad beneficiaria de los incentivos regulados en el Título III de la Ley 49/2002, de 23 de diciembre, de régimen fiscal de las entidades sin fines lucrativos y de los incentivos fiscales al mecenazgo.

- 2 Fundación legalmente reconocida que rinde cuentas al órgano del protectorado correspondiente o asociación declarada de utilidad pública a que se refieren el artículo 68.3.b) de la Ley del Impuesto sobre la Renta de las Personas Físicas.

- 3 Titular o administrador de un patrimonio protegido regulado en la Ley 41/2003, de 18 de noviembre, de protección patrimonial de las personas con discapacidad y de modificación del Código Civil, de la Ley de Enjuiciamiento Civil y de la Normativa Tributaria con esta finalidad.

- 4 Partidos Políticos, Federaciones, Coaliciones o Agrupaciones de Electores en los términos previstos en la Ley Orgánica 8/2007, de 4 de julio, de financiación de partidos políticos.

El CRM puede generar el modelo 182 para entidades cuya naturaleza sea de los tipos 1, 2 o 4, no así del tipo 3.

Porcentaje de deducción autonómica

Los donativos a determinadas entidades, al margen de la deducción a la que den derecho para el donante con carácter general, pueden otorgar un porcentaje adicional de deducción en el tramo autonómico del IRPF del donante. Si la entidad puede acogerse a este supuesto en alguna comunidad autónoma, deberá crear un registro del tipo M182_PORCENTAJE_DEDUCCION_AUTONOMICA_XX en el módulo de Configuración e indicar el porcentaje deducible en la comunidad correspondiente. Los caracteres XX se asignarán según la siguiente tabla de equivalencias:

  • Andalucía 01
  • Aragón 02
  • Principado de Asturias 03
  • Illes Balears 04
  • Canarias 05
  • Cantabria 06
  • Castilla - La Mancha 07
  • Castilla y León 08
  • Cataluña 09
  • Extremadura 10
  • Galicia 11
  • Madrid 12
  • Región de Murcia 13
  • La Rioja 16
  • Comunidad Valenciana 17

Persona de contacto

La cadena formada por "M182_PERSONA_CONTACTO_NOMBRE + espacio + M182_PERSONA_CONTACTO_APELLIDO_1 + espacio + M182_PERSONA_CONTACTO_APELLIDO_2" no puede exceder los 40 caracteres.


Volver al índice