12 respuestas en este tema

[mestor]

Buenos días,

de cara a la generación de remesas de recibos bancarios dentro de poco se sustituiran los actuales cuadernos 19 y 34 por la norma SEPA.

¿Alguien tiene información al respecto relacionada con la forma de generar esos recibos desde Delphi?

De cara a una información general existe una web que lo explica por si os interesa:

http://www.sepaesp.es/sepa/es/

Un saludo

[ELKurgan]

Gracias por el aporte, compañero

[poliburro]

Gracias por el aporte

[Nasca]

Buff, lo tengo dolorosamente fresco. Recién acabo de tragármelas para implementarlas en mi ERP. http://criterium.es/tags/sepa

Tira de las normas bancarias en formato básico, formato texto plano como hasta los actuales. 19.14, 19.44 y 34.14. Algunos sitios dónde descargar las normas:
http://empresa.lacai...as_de_migracion
https://www.cajamar....mun/sites/sepa/

La mayoría de las entidades están llegando tarde al SEPA, así que tiran de las que conocen. Las normas en formato XML no son obligatorias hasta 2016 y muchas de las entidades financieras directamente ni las implementarán.

A la hora de generarlas en Delphi no hay problema, no dejan de ser archivos de texto plano. Ni siquiera la conversión de texto es necesaria ya que la mayoría de las entidades soportan el ISO8859-1.

Unos apuntes.
Tendrás que calcular el IBAN en base a las cuentas CCC. No es muy complejo de hacer. El BIC/SWIFT dejará de ser obligatorio en transferencias nacionales el 01/02/2014. Lo ideal es que aproveches y montes un sistema de depuración de cuentas obsoletas. El mercado bancario en España está hecho una mierda, así que muchas cuentas directamente no existirán y pueden darte problemas al pasar a SEPA. Si quieres puedes descargar el listado de entidades desde el banco de España. Aunque no lleva toda la información necesaria, si es un buen punto de partida: http://www.bde.es/bd...gistros_de_Ent/

La norma 34.14 no tiene mayores complicaciones que adaptar las anteriores 34 al uso del IBAN y BIC.

En la norma 19.14/15 y 19.44 es dónde se añade una complejidad adicional. En las anteriores normas 19 solo había que indicar una referencia de domiciliación, que se podía inventar y listo. Ahora es mas complicado ya que a los datos anteriores, referencia de domiciliación y de acreedor, se añaden otros: tipo de adeudo y fecha de aceptación del mandato/domiciliación.
Si ya gestionabas los las normas 19 anteriormente en tu software esto va a suponer añadir campos adicionales al registro de clientes o una tabla independiente para el registro de mandatos/domiciliaciones. Esta última opción es la mas interesante y flexible, es la que yo he adaptado.

[seoane]

En esto mismo me encuentro yo ahora, con el agravante de que mi jefe lo quiere tener "todo listo" para enero y yo me voy de vacaciones esta semana 

Por cierto, eso de calcular el IBAN a partir del CCC, aunque es muy sencillo, en las recomendaciones SEPA dice explícitamente que no se debe hacer, y que se debe pedir el IBAN al cliente. Incluso hay plantillas con el formulario que los clientes deben rellenar, y devolver firmado. En mi empresa ya hemos enviado las cartas pertinentes a los clientes para que devuelvan los formularios firmados, aunque no veo a las compañías de teléfono o de electricidad haciendo los mismo con millones de clientes, me imagino que esas lo calcularan de forma automática y nadie protestara.

Seguro que volveremos sobre este tema mas veces de aquí a febrero 

Saludos

[seoane]

Como comentaba ayer, se recomienda no calcular el IBAN:

¿Puede el emisor de los pagos extraer el IBAN a través del CCC? 

Existe una herramienta que permite verificar de una manera sencilla el código IBAN correspondiente a un CCC. No obstante, aunque el código IBAN de una cuenta se obtiene a partir del CCC, para mayor seguridad en los pagos se desaconseja efectuar su cálculo, debiendo recabarlo siempre de forma íntegra de su contrapartida. Sólo mediante este procedimiento se puede asegurar la idoneidad de la información.

[Sergio]

En el proceso de transpaso a SEPA de datos existentes lo normal será generar el IBAN, hoy mismo me ha llegado un email de google diciendome que mi cuenta de wallet ya tenía el IBAN que me habían calculado ellos para ahorrarme problemas, esa sera la manera porque, además, las domiciliaciones antiguas no tienen un documento de autorización firmado ni nada de eso, no era obligatorio, por lo que la fecha de ese documento, que es obligatoria en el formato, será inventada (31/10/2009 concretamente).

Otra cosa será en datos nuevos, en esos el IBAN ya te llegará escrito en el documento que te ha de firmar el cliente y no tiene sentido inventarselo, pero para la transición, nosotros vamos a añadir ese dato en una actualización automática y listo.

Por si os interesa, este es el mensaaje de google:

Estimado cliente:

La cuenta bancaria que Google tiene registrada (que termina en 2440) se ve afectada por la decisión del Consejo Europeo de Pagos denominada SEPA, por la que su cuenta debe comenzar con el código internacional de cuenta bancaria (IBAN).

Para su comodidad, hemos convertido su número de cuenta al formato IBAN para que pueda seguir utilizándola para recibir pagos de los servicios de Google. No tiene que realizar ninguna otra acción para seguir utilizando esta cuenta bancaria.

A modo de referencia, la cuenta bancaria que Google tiene registrada se utiliza, o se ha utilizado, para recibir pagos de los servicios que se indican a continuación:

Google Wallet Merchant Center: 111111111111111111 (número falso)

Atentamente,
El equipo de Google Wallet

[Nasca]

Esa coletilla de no calcular tiene la pinta de ser para curarse un poco en salud los que la han redactado.

Lo cierto es que incluso las entidades financieras están realizando conversiones automáticas a IBAN.

Además muchas de ellas, incluso grandes bancos, ni siquiera han implementado las normas SEPA aún.

Con esto como con tantas cosas no hay que pecar de ser mas papista que el papa. Si la CCC española está convenientemente validada, es absurdo meterse en peticiones innecesarias a clientes y proveedores.
Bastante trabajo tendrán nuestros clientes en actualizar las cuentas de bancos extintos que pueden empezar a dar problemas con la nueva norma. Al ser una norma de alcance europeo se supone que pueden permitir menos chapuzas que si es de alcance meramente nacional.
Aunque los bancos están haciendo también sus chapuzas. Por ejemplo hoy me han pasado un documento del Banco Sabadell que calculaba la referencia del acreedor en la norma 19.14/15/44, que lleva unos dígitos de control, erróneamente ya que anteponía el sufijo a los dígitos de control.

Me filosofía aquí es simplificar la vida todo lo posible al usuario calculando el IBAN que ya tendrá bastante luego para depurar cuentas y normas con sus entidades. Ahora mismo en la mayoría de las oficinas de "SEPA no SEPO"

[Sergio]

El AEB (Asociacion Española de Banca) tiene un doc http://www.aebanca.e...0-201300427.pdf sobre la transición a SEPA, en él aclara la cuestión de generar el IBAN o pedirlo al banco:

Migración al formato IBAN para las cuentas de los deudores

La asignación de IBAN pue de ser un problema pues no siempre estará al alcance del acreedor, si no dispone en origen de un CCC correcto.

Solución: Será obligatorio disponer del número de cuenta (CCC) completo y correcto para poder efectuar la migración de las operaciones. Los emisores de adeudos pueden hacer uso del “Fichero de comunicación de datos informativos de las entidades de depósito a los clientes ordenantes (Anexo 5 del folleto 19)” para la actualización de los números de cuenta de sus clientes.

Es decir, que si ya tienes los 20 dígitos de la cuenta, con sus dos dígitos de control (se permite poner ** si no se tiene n, aunque son calculables, claro) el IBAN lo calculas y listo, y si no tienes esos 20 dígitos completos (ya sería raro, pero bueno, el formato antiguo permitía por un lado obviar los 2 dígotos de control e incluso indicar una cuenta a lo bruto: Cuenta 312 Banco Santander, Tarrevieja" y era válido pero el banco te cobrába mucho por cursar tu orden así) pues entonces le has de preguntar al banco usando un mecanismo que la verdad, desconozco pero veo que existe.

[Nasca]

Lo del anexo 5 de la norma 19 queda muy bonito sobre el papel, pero la realidad es que luego no funciona.
Al final hay que puentear a las oficinas y enviarlas a sistemas para que devuelvan la validación de cuentas. Pero ni con esas hay garantías, cada banco va a la suya.

Además de que no vale para validad beneficiarios por transferencia de la norma 34.

No obstante yo lo he implementado, pero me temo que con una utilidad real por determinar:

http://criterium.es/...traves-norma-19

[alexmiu]

En http://www.sepa-converter.com.es
hay un excel con macro que hace eso, barato, y con una demo funcional 100%

[Sergio]

En http://www.sepa-converter.com.es
hay un excel con macro que hace eso, barato, y con una demo funcional 100%

Mucho ojo, un conversor automático a SEPA en general no vale, porque antes en el formato 34 no aparecían ciertos datos obligatorios en el SEPA, y si te los inventas sin más... pues no vale.

Por ejemplo:

-La fecha en que se firmo el mandato SEPA donde tu cliente te permite pasarle recibos es ahora obligatorio, y en contratos modernos no vale poner una fecha inventada, tiene que ser la buena.

-El número de mandato SEPA: Al emeitir la autorización para que te la firmen ha de ir numerada, y ese numero ha de ir en el fichero SEPA, y de nuevo no vale inventarselo.

-El IBAN tampoco vale con generarlo a partir del ccc, y ojo que el formato antiguo no tenia espacio para IBAN, por lo cual el conversor se lo va a inventar. En general vale, pero muchas ccc son cuentas antiguas de bancos absorvidos por otros, esos ccc no son válidos pero se admitian porque el banco hacia la conversión internamente. El IBAN que le calcules a esas cc es invalido, porque la entidad no está en la lista de entidades adheridas al SEPA.

-El código BIC es obligatorio para algunas entidades, aunque en general no lo sea. Ese código BIC solo es calculable a partir del código de banco (4 digitos primeros) pero, de nuevo, entidades que han desaparecido no tienen asignado un BIC para el banco, evidentemente, por lo que el generador de BICs (existe una tabla de entidades con sus BICs) te va a dejar esas cuentas sin BIC (así es como detectamos nosotros cuentas obsoletas en nuestra aplicación).

Aparte está el lio de los formatos SEPA "chapuceros" solo válidos en España (de transición les llaman) que son txt como eran los antiguos, y los SEPA "de verdad" que valen en toda Europa. Este es XML y casi ningún banco español los admite actualmente (una verguenza que no hayan saltaod a XML de un golpe, supongo que el cobol que usan aún no sabe de xml).

[Nasca]

Efectivamente, la cosa tiene su tela, aunque si solo se procesa la norma 34 de transferencias la conversión es mas directa. La 19 si tiene toda la problemática que explica Sergio. También la secuencia del recibo, primero o recurrente, puede dar alguna sorpresa.

Luego te encuentras implantaciones de las normas por parte de los bancos muy particulares que directamente se saltan las normas. Más en la implantaciones XML que las tienen mas verdes, pero también en el formato básico:

• Se saltan la indicación de con relación/sin relación o la invierten
• Restringen los caracteres válidos
• Obligan a poner datos opcionales, etc

Muy entretenido el tema y luego al final hay que conceder con la chulería de los técnicos del banco y adaptarse a sus implementaciones defectuosas.