Formas de pago, Pagos y Remesas

De SinergiaCRM
Saltar a: navegación, buscar

Conceptos básicos

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:

- Forma 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 forma 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 una forma de pago. En el caso de una donación puntual una forma de pago llevará asociado, normalmente, un único pago. En el caso de una cuota periódica, una forma de pago llevará asociados múltiples pagos. Así como las formas 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.

Los módulos de Formas de pago y Pagos son particularmente sensibles a cambios realizados por el usuario en los diseños y otros elementos. Es recomendable, pues, tener mucho 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:

- Número de cuenta: 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 SEPA_VALIDATE_IBAN es posible activar o desactivar con carácter general la validación del IBAN en el campo Número de cuenta. Por defecto la constante toma el valor 1, que indica que el campo Número de cuenta 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 Número de cuenta 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 Formas 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 introduce el número de cuenta, 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 una forma 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 / Formas de Pago).

Vista de edición de una forma de pago

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

- Nombre (de la forma 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 (Formas 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 que realiza el compromiso de pago. De no cumplimentarse uno de los dos campos, la aplicación lanzará un aviso.

- Destino: puede asociarse la forma 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 Destino: aquí se detalla el destinatario o beneficiario de la forma de pago que se genera. Estas formas 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, Transferencia, 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 Número de cuenta y Mandato. En relación a estos dos campos, el usuario sólo debe introducir los 24 dígitos numéricos (sin otros caracteres ni espacions) en el campo Número de cuenta. Al abandonar este campo, el CRM generará automáticamente el valor del Mandato. En este último caso se genera un valor numérico aleatorio único que la entidad puede sobrescribir con su propio código en caso de contar con él (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 forma de pago periódica.

- Canal y campaña a través de los cuales se ha originado la forma 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 una única forma de pago, el campo importe puede dejarse en blanco.

- Fecha de primer pago: aparece por defecto la fecha en que se da de alta la forma 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 movimiento: Ingreso o Gasto. Permite caracterizar una forma 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 las correspondientes constantes.

 

Una parte importante de los datos asociados a una forma de pago son heredados por los pagos asociados a la misma (Importe, Número de cuenta, 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 una forma de pago:

- De cambiar, por ejemplo, el Importe o el Número de cuenta de una forma 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 la forma de pago vigente y dar de alta una nueva forma de pago con los nuevos datos.

 

Pago inicial y estado de los pagos

Tras la creación de cualquier forma 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 dicha forma 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 la forma 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_MES_GENERACION_PAGOS 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 la forma de pago de origen (importe, tipo de pago, número de cuenta, 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).

- Tarjeta: el estado de los pagos generados es Pagado. Dado que legalmente no es posible almacenar los datos de la tarjeta para usos futuros, al crearse una forma de pago vinculada a este medio de pago es de suponer que el pago ya ha sido realizado.

- Otros medios (Transferencia emitida, Transferencia emitida, Efectivo, Talón, En especie): 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, Recobro, Impagado, Duplicado, Rechazado TPV) están relacionados con el ciclo de gestión de las remesas bancarias y/o pueden ser utilizados por parte de la entidad para la gestión manual de los procesos no automatizados (remesas bancarias, TPV o Paypal).

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, Recobro, 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 las formas de pago periódicas 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 Admin/Sistema/Planificador.

Planificador. Vista de edición de la tarea programada de generación de pagos recurrentes.

 

Históricamente el CRM generaba siempre los pagos correspondientes al mes en curso en el momento de ejecutarse la tarea. Actualmente se puede elegir generar los pagos para el mes en curso, como anteriormente, o para el mes siguiente al mes en curso, de forma que 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_MES_GENERACION_PAGOS. 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 una determinada forma de pago si ésta se encuentra activa (sin Fecha de baja o con Fecha de baja futura), tiene una periocidad establecida (no es Puntual) y el mes para el que se crean los pagos coincide con Fecha de primer pago + Periodicidad. Por ejemplo, para una forma 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 una forma 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 la forma de pago (ver Pago inicial).

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 desde la entidad 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 la forma 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), Fechas de generación y de cargo de los recibos e IBAN (número de cuenta donde cargar la remesa).

Vista de edición de una remesa.

Al crear la remesa se muestra automáticamente el subpanel en el que poder seleccionar los pagos a incorporar. El criterio habitual de selección será del tipo "pagos con estado No remesada".

Vista emergente del buscador de pagos a incluir en una remesa.

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 Cuaderno 19 (fichero de texto de campos de longitud fija) o en formato SEPA (fichero XML) desde el menú del botón de acciones de la remesa (zona superior izquierda de la vista de detalle). El resultado de la operación es la descarga del fichero que deberá entregarse a la entidad financiera.

Menú de acciones de la vista de detalle de una remesa.

Para que el formato del Cuaderno 19 o 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 Constantes. En apartados posteriores se describen las constantes concretas que afectan al proceso de generación de remesas.

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

Una vez generado el fichero C19/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 es recomendable cambiar 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.

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 C19/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.

Vista de edición de una remesa. Selección del tipo para una remesa de transferencias emitidas.

Para gestionar las remesas de transferencias es necesario rellenar dos constantes específicas para este fin (Ver Constantes SEPA para remesas de transferencias).

 

Constantes C19

No debe modificarse el valor de las siguientes Constantes, pues se trata de valores fijos establecidos por la norma del C19: C19_COD_REGISTRO_INDIVIDUAL, C19_COD_REGISTRO_ORDENANTE, C19_COD_REGISTRO_PRESENTADOR, C19_COD_REGISTRO_TOTAL_GENERAL, C19_COD_REGISTRO_TOTAL_ORDENANTE. Tampoco deben modificarse sus equivalentes con el sufijo _DEVOLUCION.

- C19_CONCEPTO_OBG_INDIVIDUAL: El concepto que figura en el recibo. En las remesas C19 se usa siempre este valor, a diferencia de las remesas SEPA, que permiten sobrescribirlo con el valor que figura en la forma de pago correspondiente.

- C19_NOMBRE_ORDENANTE y C19_NOMBRE_PRESENTADOR: El nombre de la entidad usuaria del CRM.

- C19_NIF_ORDENANTE y C19_NIF_PRESENTADOR: El NIF de la entidad usuaria del CRM.

- C19_ENTIDAD_ORDENANTE y C19_ENTIDAD_PRESENTADOR: El primer grupo de 4 dígitos del número de cuenta donde se debe dipositar el importe de los recibos domiciliados.

- C19_OFICINA_ORDENANTE y C19_OFICINA_PRESENTADOR: El segundo grupo de 4 dígitos del número de cuenta donde se debe dipositar el importe de los recibos domiciliados.

- C19_DC_ORDENANTE: Los 2 dígitos de control (posiciones 9 y 10) del número de cuenta donde se debe dipositar el importe de los recibos domiciliados.

- C19_CUENTA_ORDENANTE: Los últimos 10 dígitos del número de cuenta donde se debe dipositar el importe de los recibos domiciliados.

- C19_PROCEDIMIENTO_ORDENANTE: valor suministrado por la entidad bancaria con la que la entidad tiene contratado el servicio de domiciliación. Normalmente 1.

- C19_SUFIJO_ORDENANTE y C19_SUFIJO_PRESENTADOR: valor suministrado por la entidad bancaria con la que la entidad tiene contratado el servicio de domiciliación. Normalmente 000.

 

Constantes SEPA para remesas de recibos domiciliados

- SEPA_BIC_NUMBER: BIC significa Bank Identifier Code o Código de Identificación Bancaria (también se le conoce como código SWIFT). Lo encontraréis en vuestra aplicación de banca online o os lo facilitará vuestra entidad financiera. También lo podéis obtener en este enlacea partir de vuestro número de cuenta IBAN. Nota: el BIC dejó de ser obligatorio a todos los efectos en 2016 (http://www.sepaesp.es/sepa/es/faqs/sepa/), por lo que esta constante dejó de utilizarse.

- SEPA_CONCEPTO_OBG_INDIVIDUAL: El concepto por defecto del recibo. El concepto de la forma de pago tiene prioridad sobre el valor de la constante general, pero conviene establecer el valor de esta constante para evitar que una forma de pago sin concepto genere un recibo sin concepto.

- SEPA_CREDIT_NAME: El nombre de la entidad usuaria del CRM. Equivalente a C19_NOMBRE_ORDENANTE.

- SEPA_CREDIT_SCHEME_IDENTIFICATION: 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.

- SEPA_IBAN_CREDITOR: El IBAN completo (24 dígitos) del número de cuenta donde se hará el ingreso del importe de los recibos domiciliados. Nota: actualmente se indica el número de cuenta de manera individual en cada remesa, por lo que esta constante deja de utilizarse. (Ver Operativa multicuenta/multibanco)

- SEPA_OIN_NUM: Identificador del presentador. Se puede utilizar el mismo valor que en SEPA_CREDIT_SCHEME_IDENTIFICATION.

- SEPA_PARTY_NAME: Normalmente, el nombre de la entidad usuaria del CRM. Equivalente a C19_NOMBRE_PRESENTADOR.

 

Constantes SEPA para remesas de transferencias

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

- SEPA_DEBTOR_NAME: Nombre del ordenante de la transferencía. Habitualmente será el nombre de la entidad.

 

Operativa multicuenta/multibanco

Históricamente el CRM operaba con un único número de cuenta para las remesas bancarias, configurado en el módulo Constantes. 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_ibans_list.

Edición de lista desplegable de números IBAN.

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

1. Indicar en la casilla Nombre del Elementoel 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ónel nombre con el que identificaremos la cuenta. El formato es libre pero se recomienda seguir un patrón: por ejemplo, Nombre de la entidad financiera + Últimas cuatro cifras de la 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.

Vista de edición de una remesa. Selección del IBAN asociado a la remesa.

 

Avisos y advertencias en la generación de ficheros

Al intentar generar un fichero SEPA de domiciliaciones o transferencias o un C19, 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.

Vista de detalle de una remesa. Aviso de error bloqueante en la generación del fichero.

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.

Vista de detalle de una remesa. Errores y advertencias en el fichero generado.

Una vez generado el fichero, para poder observar el texto con los problemas detectados es 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 aparecen las opciones de Cargar Devoluciones C19 y Cargar Devoluciones SEPA. Elegir la que proceda. Cabe tener en cuenta que el formato del fichero de devoluciones debe ser consistente con el formato de la remesa de recibos enviada previamente al banco: o ambos C19 o ambos SEPA, pero no mezclados.

Menú del módulo Remesas.

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

Ventana emergente para cargar el fichero de devoluciones.

- 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. Al terminar el proceso se mostrará en pantalla el mensaje FICHERO CORRECTO Y CARGADO.

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.

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

 

Menú del módulo Pagos.

 

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.

 

Asistente para la generación del Modelo 182.

 

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 el C19/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.

Como parte del proceso de generación del fichero del Modelo 182, el sistema actualiza el campo Total Donaciones M182 para cada registro de persona u organización afectado. Este campo no se muestra por defecto en las fichas de estos módulos pues su valor siempre depende de la última ejecución del Modelo 182, sin que exista posibilidad alguna de saber cuándo se ha realizado esta operación por última vez. Este campo puede ser utilizado, por ejemplo, para la elaboración de los certificados de donaciones a través del mecanismo de combinar correspondencia, siempre de forma inmediata después de la generación del Modelo 182.

 

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.

 

Registros con errores

En caso de que durante el proceso de generación del modelo 182 el CRM encuentre registros que no cumplan dichas condiciones 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.

Nota: a partir del ejercicio 2017 la Agencia Tributaria ha incorporado un control adicional 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.

 

Constantes del Modelo 182

Antes de generar el Modelo 182 es necesario configurar adecuadamente las constantes relacionadas con este modelo en el módulo de Constantes:

- 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_DECLARANTE: El nombre de la entidad (máximo 40 caracteres)

- M182_JUSTIFICANTE: Código único 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_NATURALEZA_DECL: 1, 2, 3 o 4, según proceda (normalmente 1 o 2, ver más información en las Notas adicionales)

- M182_NIF: El NIF de la entidad

- M182_PORCENTAJE_DEDUCCION: Cuando en M182_NATURALEZA_DECL se haya hecho constar el valor 1, 2 o 4, se hará constar el porcentaje de deducción aplicable a los donativos efectuados por personas físicas. A partir de la declaración del año 2015, para aquellas entidades cuya naturaleza sea de tipo 1, este porcentaje se aplica sobre los primeros 150 € donados y será del 50% en 2015 y del 75% en los años siguientes.

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

- M182_PORCENTAJE_DEDUCCION_EXCESO_NO_RECURRENTE: A partir de la declaración del año 2015, para aquellas entidades cuya naturaleza sea de tipo 1, este porcentaje se aplica sobre las aportaciones realizadas por personas físicas que excedan de 150 € y que sean consideradas no recurrentes. El valor será del 27.5% en 2015 y del 30% en los años siguientes.

- M182_PORCENTAJE_DEDUCCION_EXCESO_RECURRENTE: A partir de la declaración del año 2015, para aquellas entidades cuya naturaleza sea de tipo 1, este porcentaje se aplica sobre las aportaciones realizadas por personas físicas que excedan de 150 € y que sean consideradas recurrentes. El valor será del 32.5% en 2015 y del 35% en los años siguientes.

- M182_PORCENTAJE_DEDUCCION_PERSONAS_JURIDICAS: Cuando en M182_NATURALEZA_DECL se haya hecho constar el valor 1, 2 o 4, se hará constar el porcentaje de deducción aplicable a los donativos efectuados por personas jurídicas. Este valor está fijado en el 35% para las aportaciones consideradas no recurrentes.

- M182_PORCENTAJE_DEDUCCION_PERSONAS_JURIDICAS_RECURRENTE: A partir de la declaración del año 2015, para aquellas entidades cuya naturaleza sea de tipo 1, este porcentaje se aplica sobre las aportaciones realizadas por personas jurídicas que sean consideradas recurrentes. El valor será del 37.5% en 2015 y del 40% en los años siguientes.

- M182_RELACIONARSE_APELLIDO_1: Primer apellido de la persona de contacto

- M182_RELACIONARSE_APELLIDO_2: Segundo apellido de la persona de contacto

- M182_RELACIONARSE_NOMBRE: Nombre de pila de la persona de contacto

- M182_RELACIONARSE_TELEFONO: Teléfono de contacto que queráis poner

 

Notas adicionales sobre las constantes del Modelo 182

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

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

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_AUTONOMA_XX en el módulo de Constantes 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

A modo de ejemplo, en el CRM aparece creado por defecto el registro M182_PORCENTAJE_DEDUCCION_AUTONOMA_09, que correspondería al caso de Cataluña.

4) Persona de contacto

La cadena formada por "M182_RELACIONARSE_NOMBRE + espacio + M182_RELACIONARSE_APELLIDO_1 + espacio + M182_RELACIONARSE_APELLIDO_2" no puede exceder los 40 caracteres.

 

Volver al índice