Configuración de series de numeración y mandatos bancarios
Requisitos previos indispensables y gestión masiva de mandatos SEPA
Antes de ejecutar una remesa bancaria, es obligatorio verificar que las series de numeración del nuevo ciclo académico estén creadas y activas, ya que las del curso anterior caducan de forma automática al cambiar de periodo. Asimismo, el centro debe tener configurada la cuenta bancaria de la empresa para poder canalizar los fondos de forma electrónica. A nivel individual, cada recibo debe contener íntegros los campos de alumno, cliente, medio de pago y centro para evitar bloqueos estructurales en el procesamiento de la facturación.
Para cobros por banco, es un requisito legal indispensable registrar la fecha de firma del consentimiento del mandato de domiciliación del cliente en estado vigente. Ante omisiones o caducidades generalizadas, la plataforma incluye la utilidad Firma masiva de mandatos dentro de su configuración general, la cual permite rellenar de forma automatizada mandatos vacíos, firmar en lote los existentes y actualizar su fecha de vigor conforme a un parámetro temporal determinado. Técnicamente, la fecha de firma del mandato SEPA debe ser siempre estrictamente anterior a la fecha de cargo establecida en el lote de cobro. El alta formal de las nuevas series de numeración se realiza en el menú de configuración general, definiendo un título anualizado, periodo de vigencia, prefijo y el número de cifras proyectado, siendo obligatorio vincularlas a los centros y departamentos correspondientes para su activación. Cabe añadir que las series son exclusivas: se configuran de forma independiente para recibos o para facturas, prohibiéndose su mezcla cruzada.
Aspectos clave
- Control de vigencia anual: Validación obligatoria de las series de numeración al inicio de cada curso para evitar bloqueos por caducidad.
- Integridad documental del recibo: Cumplimentación completa de los campos de cliente, alumno, centro y medio de pago en la gestión económica.
- Preferencia cronológica del consentimiento: La fecha de firma del mandato SEPA debe anteceder obligatoriamente a la fecha de cobro de la remesa.
- Exclusividad de registro legal: Configuración e indexación de series de facturación independientes y totalmente disociadas de los recibos ordinarios.
El proceso operativo de remesas, Ticket Bai e incidencias
Emisión de cuadernos SEPA XML, particularidades fiscales y resolución de bloqueos
La remesa se inicia desde el módulo de recibos generando un nuevo registro donde se define un título organizativo y la forma de pago (habitualmente banco). También se admite procesar cobros masivos al contado para regularizar saldos internamente, aunque esta vía no genera archivo de intercambio bancario. Al fijar la fecha de cargo, se define la fecha oficial de cobro y de emisión de los recibos. El sistema muestra por defecto los recibos del mes corriente, pero permite aplicar filtros de fechas para rescatar saldos atrasados de meses previos, además de segmentar por alumno, cliente o curso específico. Al añadir los registros, se puede determinar recaudar el 100% del importe, aplicar un porcentaje parcial uniforme o definir una cuantía económica fija exacta por recibo.
Es fundamental recordar que las facturas se rigen por una lógica distinta a los recibos: deben haber sido emitidas previamente en su propio módulo sectorial para estar disponibles dentro del lote de la remesa. Tras indexar la serie de numeración, se debe constatar que el importe incluido sea igual al importe procesado y validar el estado conforme de la cuenta bancaria para proceder a descargar el fichero final en formato SEPA XML. El cobro masivo altera de inmediato el estado del recibo en Atenea, figurando como pagado.
En entornos sujetos a Ticket Bai, la ficha del cliente debe contener obligatoriamente la dirección y el NIF completos para autorizar cobros manuales o masivos. Tras procesar la remesa, el sistema firma digitalmente los registros. En Gipuzkoa y Álava, los datos se transmiten automáticamente a Hacienda como emitidos y cobrados , mientras que en Bizkaia se realiza el firmado para su posterior subida consolidada mediante la plataforma ROE. Ante errores de cuenta bancaria no validada (“Ivan no OK”) o fallos de NIF, el procedimiento exige corregir los datos en la ficha económica, extraer formalmente el recibo de la remesa (“sacar”) y volverlo a incorporar (“añadir”) para actualizar sus parámetros en el lote. Las remesas también están restringidas a un único centro de trabajo seleccionado en la cabecera, impidiendo la mezcla desordenada de cobros entre distintas sedes. Por último, para anomalías ya validadas por las Haciendas de Gipuzkoa y Álava, los errores se corrigen a posteriori empleando la utilidad integrada Zucendu.
Recomendaciones y buenas prácticas
- Conciliación cruzada de totales: Comprobar el equilibrio exacto entre el importe incluido y el procesado antes de autorizar la remesa.
- Auditoría externa de cobros: Exportar el lote remesado a formato Excel para conservar un registro detallado de clientes y alumnos asociados al cobro.
- Preemisión de facturación: Asegurar que toda factura haya sido emitida con anterioridad a su inclusión dentro del módulo de remesas bancarias.
- Segmentación estricta por sedes: Procesar lotes de remesas independientes para cada centro con el fin de evitar confusiones en la conciliación de cobros.
Conclusiones
El éxito operativo en la emisión de remesas bancarias bajo la plataforma Atenea reside en la rigurosa coherencia de sus datos maestros y en el cumplimiento estricto de las directrices bancarias y fiscales aplicables. La sincronización previa de los mandatos SEPA, junto con el mantenimiento riguroso de las series de numeración independientes y la correcta cumplimentación de fichas de clientes, erradica los bloqueos más comunes durante el cierre mensual de caja. Mediante el dominio de las funciones de filtrado temporal, los flujos de exclusión para corrección de cuentas bancarias y el uso de herramientas auxiliares de reporte como Excel, el gestor garantiza una recaudación ágil, transparente y plenamente adaptada a marcos normativos complejos como Ticket Bai.
Preguntas frecuentes (FAQ)
¿Es obligatorio ingresar el NIF del cliente para procesar la remesa de un recibo ordinario?
No, en las operaciones comerciales estándar de la plataforma Atenea el NIF del cliente no es obligatorio para remesar recibos ordinarios. Este campo se vuelve estrictamente obligatorio y validado por el sistema únicamente bajo la normativa fiscal Ticket Bai en el País Vasco.
¿Qué impacto inmediato tiene en los recibos la descarga del archivo de intercambio bancario?
En el momento exacto en que se ejecuta la orden de emisión de la remesa, Atenea altera automáticamente el estado de todos los recibos integrados en el lote, registrándolos formalmente como “pagados” e indexando su numeración correlativa correspondiente.
¿Cómo se solventa la alerta de cuenta bancaria no conforme (“Ivan no OK”) detectada en un lote?
Se deben comprobar los datos del recibo y la vigencia del mandato en la ficha de gestión económica. Tras subsanar el error, el usuario debe extraer el recibo de la remesa mediante el botón de exclusión (“sacar”) y volverlo a indexar (“añadir”) para forzar la actualización de datos en el lote.
¿Es posible consolidar y unificar los recibos de múltiples centros educativos en un solo lote de remesa bancaria?
No de manera directa. Cada remesa se encuentra vinculada de manera unívoca a un único centro de trabajo seleccionado en la cabecera operativa. Aunque el buscador muestre registros de otras sedes, los cobros finales procesados pertenecerán con exclusividad al centro delimitado en la configuración superior.
¿Se pueden procesar transacciones masivas bajo la modalidad de pago al contado a través del módulo de remesas?
Sí, la plataforma permite parametrizar la forma de pago de la remesa en la modalidad de contado para asentar de forma masiva el cobro de un lote de recibos internamente. No obstante, este procedimiento netamente administrativo no genera ningún fichero de intercambio SEPA para presentar ante bancos.
