función paso CCC a IBAN

[Francisco Alemañ Baeza]

Alguno tiene la función de paso de CCC (codigo cuenta corriente) a IBAN para la comunidad europea? Por el tema de los cuadernos nuevos

19-14 del SEPA.?

[Jose Antonio Blasco]

Yo he sacado la información de esta pagina:

http://www.finanzasybanca.com/iberfinanzas/index.php/C/Codigo-Internacional-de-Cuenta-Bancaria-IBAN.html

Un saludo.

Jose A. Blasco
Zaragoza - España
Visual FoxPro 9 SP2

"No hay camino hacia la libertad, la libertad es el camino" - Indira Gandhi
“Nunca te olvides de sonreír, porque el día que no sonrías  será un día perdido”  -  Charles Chaplin
“Todo el mundo quiere tener un amigo, pero pocos se toman la molestia de ser uno” - Anónimo

[Luis M.]

Y siguiendo con el tema, ¿alguien sabe cómo quedarán finalmente los envíos de adeudos y transferencias? (anteriores cuadernos 19-58 de adeudos y 34 de transferencias)

(He estado indagando un poco y no veo claro si los nuevos formatos deben ser en formato texto, XML, así como las diferencias entre el Core y B2B)

Gracias y un saludo,

Luis Martínez.

[Jose Antonio Blasco]

El cuaderno 58, se prorroga hasta Feb.2016.

Los cuadernos 19 y 34, tienes 2 opciones, pasar por un formato plano, que será provisional hasta Feb.2016, o bien directamente al formato XML.

Puedes conseguir información en  www.sepaesp.es

Un saludo.

Jose A. Blasco
Zaragoza - España
Visual FoxPro 9 SP2

"No hay camino hacia la libertad, la libertad es el camino" - Indira Gandhi
“Nunca te olvides de sonreír, porque el día que no sonrías  será un día perdido”  -  Charles Chaplin
“Todo el mundo quiere tener un amigo, pero pocos se toman la molestia de ser uno” - Anónimo

[Miguel A.]

Hola Jose A.

 

¿Me  puedes aclarar de qué va esto?.

 

Ha cambiado algo a la hora de emitir recibos  un cliente, o de qué va este rollo?.

Esto que comentáis  de los cuadernos 19, 34 y no sé... me suena a chino, pero me siento aludido porque yo sé que tú estás en Zaragoza y yo en Madrid, o sea que estoy viendo mis barbas remojar....

 

Gracias payo, dime algo...

Miguel A.

[Luis M.]

Gracias Jose A.

Voy a investigar por el lado del XML que parece el formato definitivo.

Saludos,

Luis Martínez.

[Jose Antonio Blasco]

Miguel A.,  a partir del 1 de Febrero de 2014, dejará de usarse en todas las entidades bancarias de la Unión Europea, el Codigo Cuenta Cliente o CCC que usamos actualmente en España de 20 dígitos y sus equivalentes en Eurpoa, para usarse el IBAN que es común en la Unión Europea.  En España tendrá 24 caracteres, pero dependiendo de los paises, puede llegar a 35 carácteres.

Con respecto a los cuadernos, son los conocidos CSB19, CSB34 y CSB58,  que luego pasaron a la AEB, se puede encontrar la información en la página:

http://www.sepaesp.es

Un saludo.

Jose A. Blasco
Zaragoza - España
Visual FoxPro 9 SP2

"No hay camino hacia la libertad, la libertad es el camino" - Indira Gandhi
“Nunca te olvides de sonreír, porque el día que no sonrías  será un día perdido”  -  Charles Chaplin
“Todo el mundo quiere tener un amigo, pero pocos se toman la molestia de ser uno” - Anónimo

[Jose Antonio Blasco]

Luis M.,  lamentablemente, hasta ahora no he usado nunca XML, por lo que, teniendo en cuenta las fechas, voy a tener que pasar por los ficheros planos provisionales hasta Feb.2016, para tener más margen y estudiarlo a fondo.

Un saludo.

Jose A. Blasco
Zaragoza - España
Visual FoxPro 9 SP2

"No hay camino hacia la libertad, la libertad es el camino" - Indira Gandhi
“Nunca te olvides de sonreír, porque el día que no sonrías  será un día perdido”  -  Charles Chaplin
“Todo el mundo quiere tener un amigo, pero pocos se toman la molestia de ser uno” - Anónimo

[Luis M.]

Hola Jose A., 

¿Y si probamos a colaborar en este tema? (sé que a veces estas colaboraciones se quedan en nada, pero quizás puede ser productivo).

Yo he trabajado con XML en un par de proyectos, eso sí, construyendo los archivos manualmente con sus etiquetas XML mediante TEXT - ENDTEXT y luego grabando el "chorizo" construido con STRTOFILE

Saludos,

Luis Martínez.

Logroño - La Rioja.

[Miguel A.]

Gracias José A.

 

Por lo que veo el CCC se sustituye por el IBAN, pero tampoco veo que esto sea un problema irresoluble, es una rutina bastante sencilla.

 

Pero... Todo eso que habláis de sobre XML, ¿qué pasa que ahora por ejemplo los recibos o las transferencias habrá que enviar un fichero de este tipo en vez del TXT que se enviaba hasta ahora? En caso afirmativo me podéis decir de dónde puede descargarme un ejemplo para ver la estructura del XML.

 

Como Luis, también hago para otras cosas, por ejemplo la facturae, los XML en plan chorizo (se nota que Luis es riojano, qué rico es el chorizo riojano, xD!!!), lo importante es que al final funcione y eso no creo que tampoco sea tan complicado.

 

Ahora mismo esto con muchísimo trabajo, pero en cuanto encuentre un hueco y la información necesaria os diré algo y os mandaré mis avances al respecto.

 

Saludos,

Miguel A.

[Luis M.]

Hola Miguel A. (llevas razón con lo del chorizo y... no se te olvide el vino:-)

Efectivamente la rutina de conversión de CCC a IBAN es el menor de los problemas.

Existe la posibilidad de un formato transitorio en formatos planos que serviría hasta el 1 de febrero de 2016, pero que si no me equivoco también habría que hacer nuevo (no es el mismo de la norma 19 y 34), por lo que en mi opinión es mejor pasar directamente al formato XML que es el definitivo.

Para mas información, (aparte de la página del SEPA que ya ha comentado Jose A.) te mando un par de enlaces que explican la estructura de Adeudos y Transferencias en formato XML (yo todavía estoy en la fase de estudiarlos).

http://empresas.bankia.es/Ficheros/CMA/ficheros/N1914_Esq_Basico_xml.PDF

http://empresas.bankia.es/Ficheros/CMA/ficheros/Norma3414_xml.PDF

Saludos,

Luis Martínez.

[Miguel A.]

Muchas gracias Luis,

 

Echaré un vistazo a esas páginas, me tranquiliza que no sea inminente la implantación, pero aún así intentaré avanzar con esto en cuanto tenga un hueco

 

Por cierto, me encanta el vino de tu tierra y el jueves tendré ocasión de degustar alguno de vuestro caldos, ya que estaré en Logroño, en este evento: http://www.esrioja.es/index.php/empresas/item/859-los-emprendedores-riojanos-tienen-una-cita-el-21-de-noviembre-en-riojaforum

 

Saludos,

Miguel

[Miguel A.]

Hola,

 

Como hoy llueve sin descanso he preparado este prg, que nos permite saber el IBAN, a partir e la CCC y también saber si ésta es correcta o tiene algún error.

 

Saludos,

Miguel A.

[Luis M.]

Gracias por el aporte, Miguel A.

Por otro lado decirte que es bastante inminente la implantación (1 de febrero de 2014), osea dentro de "cuatro días".

Saludos,

Luis.

P.D. En cuanto a tu visita del jueves, me ofrezco a convidarte a unos vinos de mi tierra y comentamos todos estos temas.

[Jesús RA]

Muy buenas a todos,

me uno a este tema, ya que también me han encargado en mi compañía la tarea de pasar los CCC a IBAN.
Como bien comentáis, para mi también supone un desarrollo el tener que generar un fichero de texto plano, y al ser algo transitorio creo que lo mejor será ir directamente contra el XML.

A ver si entre todos vamos dando un empujen a este tema.

Saludos!

[Francisco Alemañ Baeza]

Añado el enlace que se ha puesto por ahí del XML de pagos SEPA

http://docs.oracle.com/cd/E39564_01/doc.91/e39169/fields_sepa_pay_file_appx.htm#EOAEL01692

[Francisco Alemañ Baeza]

Para la letra del pais...

cPAIS=UPPER(ALLTRIM(cPAIS))

DO CASE

CASE cPAIS="ANDORRA"

cLETRA="AD"

CASE cPAIS="AUSTRIA"

cLETRA="AT"

CASE cPAIS="BELGICA" OR cPAIS="BÉLGICA"

cLETRA="BE"

CASE cPAIS="CHIPRE"

cLETRA="CY"

CASE cPAIS="DINAMARCA"

cLETRA="DK"

CASE cPAIS="ESLOVENIA"

cLETRA="SL"

CASE cPAIS="ESTONIA"

cLETRA="EE"

CASE cPAIS="FINLANDIA"

cLETRA="FL"

CASE cPAIS="FRANCIA"

cLETRA="FR"

CASE cPAIS="ALEMANIA"

cLETRA="DE"

CASE cPAIS="GIBRALTAR"

cLETRA="GI"

CASE cPAIS="GRECIA"

cLETRA="GR"

CASE cPAIS="HUNGRIA"

cLETRA="HU"

CASE cPAIS="ISLANDIA"

cLETRA="IS"

CASE cPAIS="IRLANDA"

cLETRA="IE"

CASE cPAIS="ITALIA"

cLETRA="IT"

CASE cPAIS="INGLATERRA" OR cPAIS="REINO UNIDO"

cLETRA="GB"

CASE cPAIS="LITUANIA"

cLETRA="LT"

CASE cPAIS="LUXEMBURGO"

cLETRA="LU"

CASE cPAIS="HOLANDA"

cLETRA="NL"

CASE cPAIS="NORUEGA"

cLETRA="NO"

CASE cPAIS="POLONIA"

cLETRA="PL"

CASE cPAIS="PORTUGAL"

cLETRA="PT"

CASE cPAIS="REPUBLICA CHECA"

cLETRA="CZ"

CASE cPAIS="REPUBLICA ESLOVACA"

cLETRA="SK"

CASE cPAIS="ESPAÑA"

cLETRA="ES"

CASE cPAIS="SUECIA"

cLETRA="SE"

CASE cPAIS="SUIZA"

cLETRA="CH"

OTHERWISE

cLETRA="ES"

ENDCASE

El miércoles, 13 de noviembre de 2013 19:35:16 UTC+1, Francisco Alemañ Baeza escribió:

[Juanpa]

Me uno al debate ya que a mi también me afecta.

Completando el aporte de Francisco, además del código de letra correspondiente a cada país, también es necesario para los cálculos saber su valor numérico según la siguiente tabla:

A  = 10  G  = 16  M  = 22  S  = 28  Y  = 34
B  = 11  H  = 17  N  = 23  T  = 29  Z  = 35
C  = 12  I  = 18  O  = 24  U  = 30  
D  = 13  J  = 19  P  = 25  V  = 31  
E  = 14  K  = 20  Q  = 26  W  = 32  
F  = 15  L  = 21  R  = 27  X  = 33

Teniendo esto en cuenta y el aporte de Francisco podríamos crear una función / método que quedaría más o menos así:
*****************************************************************************************
LPARAMETERS tcPais
LOCAL lcLetra, lcNumero, lcCadena
tcPais=UPPER(ALLT(tcPais))
DO CASE
    CASE tcPais="ANDORRA"
        lcLetra="AD"
    CASE tcPais="AUSTRIA"   
        lcLetra="AT"
    CASE tcPais="BELGICA" OR tcPais="BÉLGICA"
        lcLetra="BE"
    CASE tcPais="CHIPRE"
        lcLetra="CY"
    CASE tcPais="DINAMARCA"
        lcLetra="DK"   
    CASE tcPais="ESLOVENIA"
        lcLetra="SL"   
    CASE tcPais="ESTONIA"
        lcLetra="EE"   
    CASE tcPais="FINLANDIA"
        lcLetra="FL"   
    CASE tcPais="FRANCIA"
        lcLetra="FR"   
    CASE tcPais="ALEMANIA"
        lcLetra="DE"   
    CASE tcPais="GIBRALTAR"
        lcLetra="GI"
    CASE tcPais="GRECIA"
        lcLetra="GR"
    CASE tcPais="HUNGRIA"   
        lcLetra="HU"
    CASE tcPais="ISLANDIA"
        lcLetra="IS"
    CASE tcPais="IRLANDA"
        lcLetra="IE"
    CASE tcPais="ITALIA"
        lcLetra="IT"
    CASE tcPais="INGLATERRA" OR tcPais="REINO UNIDO"
        lcLetra="GB"
    CASE tcPais="LITUANIA"
        lcLetra="LT"
    CASE tcPais="LUXEMBURGO"
        lcLetra="LU"
    CASE tcPais="HOLANDA"
        lcLetra="NL"
    CASE tcPais="NORUEGA"
        lcLetra="NO"   
    CASE tcPais="POLONIA"
        lcLetra="PL"   
    CASE tcPais="PORTUGAL"
        lcLetra="PT"   
    CASE tcPais="REPUBLICA CHECA"
        lcLetra="CZ"   
    CASE tcPais="REPUBLICA ESLOVACA"
        lcLetra="SK"   
    CASE tcPais="ESPAÑA"
        lcLetra="ES"   
    CASE tcPais="SUECIA"
        lcLetra="SE"   
    CASE tcPais="SUIZA"
        lcLetra="CH"   
    OTHERWISE
        lcLetra="ES"   
ENDCASE

lcCadena = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
lcNumero = STR(AT(LEFT(lcLetra, 1), lcCadena) + 9, 2) + STR(AT(RIGHT(lcLetra, 1), lcCadena) + 9, 2)

RETURN lcLetra + "," + lcNumero
**********************************************************************************************************

Con esta función podemos ampliar facilmente la publicada por Miguel A. para crear el IBAN a partir del CCC de manera que sirva para cualquier pais.


De todas formas esto solo es un primer paso, ya que, como ya habeis comentado, lo más complejo es crear el archivo XML.

Un saludo,
----------------------------------------
Juan Pablo Martín Peinado
Guadalajara - España
----------------------------------------

[Jesús RA]

Muy buenas,

mucho se habla del paso a XML, pero ¿alguien a pensado en el caso contrario? ¿Cómo nos va a comunicar el banco las devoluciones, en XML? ¿cómo asume esto fox?

Saludos

[Juanpa]

He estado buscando información relacionada en otros grupos de VFP y en encontrado esto .
Tienen creada una clase que al parecer crea el XML. Adjunto los archivos que me he descargado de ese grupo (creo que no estoy cometiendo ninguna irregularidad ya que cualquiera los puede descargar previa inscripción).
Todavía no he tenido tiempo de examinarlo. Hay un PDF (en perfecto francés).

Supongo que habría que hacer algún retoque, pero nos puede servir como base para empezar.

Un saludo,

-------------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España

-------------------------------------------------

[Jesús RA]

Gracias Juan Pablo, voy a echarle una ojeada.

Saludos

[Miguel A.]

Hola a todos

Ya estamos varios implicados en esto. Personalmente tengo unos días terroríficos y no puedo dedicar nada de tiempo a esto, pero creo que alguien debería nombrarse como coordinador del proyecto e ir aglutinando el código y las aportaciones, no tiene mucho sentido que todos hagamos una aplicación personal.

Reitero que me encantaría colaborar pero solo estaré enganchado a través del móvil hasta el viernes. Saludos
Miguel A.

[Juanpa]

Buenas,

He estado investigando un poquito más sobre el tema. Para empezar, el ejemplo que envié el otro día tomado de otro foro, creo que NO es exactamente lo que necesitamos, ya que se refiere al formato (pain.001.001.02) que al parecer se utiliza para transferencias. Para domiciliar recibos creo que es el formato (pain.008.001.02). Los formatos son parecidos pero no iguales.

El formato (pain.008.001.02) consta de 4 bloques: A- Raiz del mensaje, B- Cabecera, C- Información del pago y D- Información del adeudo directo individual.

Pienso que se podría crear una clase que encapsule la creación del fichero XML. De esta forma serviría para cualquiera. La clase podría tener distintos métodos, cada uno de los cuales se encargaría de crear un bloque del fichero XML y devolvería una variable tipo caracter con el contenido de cada bloque. Una vez creados los distintos bloques se unirán en una sola cadena de caracteres y se guardarán en el archivo XML mediante STRTOFILE().

Hay que tener en cuenta que el bloque B (cabecera) debe informar del nº total de operaciones, por tanto, este bloque debería crearse el último, aunque a la hora de montar el archivo XML se ponga después del bloque A.

Para que cada método pueda crear su parte del archivo necesitará tener una información. Esta información se puede pasar como parámetros a cada método o bien crear unas propiedades en la clase para cada dato y asignar los valores que correspondan antes de llamar a cada método. Personalmente esta segunda opción me gusta más.

En fin, esto puede ser una idea general de como hacerlo. Se admiten sugerencias.

Yo personalmente no voy a poder ponerme de lleno con ello hasta dentro de una o dos semanas.

Un saludo,

-----------------------------------------------
Juan Pablo Martín Peinado
Guadalajara - España
-----------------------------------------------

[Luis M.]

Yo veo muy acertado tu planteamiento de clase para la creación de cada parte del XML. En mi caso también espero poder abordar este tema en unos días.

Saludos,

Luis Martínez.

[Francisco]

En el ejemplo en frances que pusiste (aqui), se crea la estructura del XML a partir del fichero txt del formato anterior. Creo que sería mejor, crear directamente el XML de los datos sin tener que pasar por la creación del formato...

[Francisco Alemañ Baeza]

¿Algún avance de código al respecto?

[Joaquin Marti Albella]

En este enlace hay un programa para clipper/harbour que se puede transformar a vfp, no lo he probado, pero genera los ficheros para normas AEB adaptadas a SEPA

https://github.com/QuimFerrer/sepa

Lo he sacado de este foro

http://forums.fivetechsupport.com/viewtopic.php?f=6&t=25369&start=30

[Miguel A.]

Hola a todos, y antes de nada, que tengáis un próspero 2014!.

Estoy de acuerdo con la forma que propone Juan Pablo para resolver la cuestión, pero no manejo bien el tema de las clase, por lo que os cuento la forma en la que me he propuesto resolverlo yo.

Parto del hecho de que dispongo de un formulario para pasar recibos al cobro en el que voy trasladando cada apunte a una tabla y al final, al generar el fichero txt, transformo cada apunte en una línea; finalmente coloco las líneas resumen, o el pié de este fichero txt.

Bien, pues para hacer un fichero XML tengo pensado algo similar, por no decir igual:

- Parto de una tabla que tiene los campos necesarios para incluir todos los datos de cada apunte: IBAN, BIC, IMPORTE, etc., También hay un campo memo (XML_SEPA) para guardar un texto XML. Esta tabla inicialmente dispone únicamente de 2 registros:

1) que tiene en ese campo el texto XML con la raíz y cabecera  o encabezado del grupo; y

2) que tiene en dicho campo el texto XML de un elemento de pago genérico.

Los restantes campos de estos 2 registros inicialmente están vacíos, o no existen.

Me propongo, a partir del primer apunte, anotar los datos necesarios para cada adeudo, y también sustituir el campo (XML_SEPA) por el del registro 2 (el que tiene el pago genérico).

Cuando termine de hacer todos los apuntes, en el momento de confecciona el XML, lo que haré será rellenar el espacio entre etiquetas en el campo  (XML_SEPA) y reemplazar el contenido de un campo  XML_SEPA2 que tiene el apunte concreto de cada adeudo. También habrá que rellenar los datos de totales en el primer registro, y rellenar de forma adecuada el campo XML_SEPA2.

Al final con un copy memo XML_SEPA2 to &MiFicheroXML additive crearé el fichero XML en la ubicación deseada.

Mi mayor duda está en cómo se va a canalizar esto por cada Banco, ya que a pesar de que trabajamos con 5, ningún ha sabido hasta este momento aclararme ninguna cuestión a este respecto. Si no encontramos algún colega en el sector que nos ayude con los primero ejemplos, no veo la luz al final del camino, Por lo menos en este aspecto creo que es donde deberíamos ayudarnos.

Saludos

Miguel A.

El miércoles, 27 de noviembre de 2013 14:02:37 UTC+1, Juanpa escribió:

[Juanpa]

Hola Miguel,

Lo que comentas de los bancos, a mi me pasa lo mismo, no ofrecen ninguna ayuda. Da la sensación de que ni ellos mismos lo tienen muy claro, al menos con las personas que he hablado. Supongo que tendrán informáticos que sí estarán bien informados del tema, pero no he tenido ocasión de hablar con ellos. Me imagino que la forma de hacer llegar los archivos a los bancos será igual que ahora: a través de su web o llevarlos en persona en algún soporte magnético.

En cuando a la forma de crear el archivo XML, cada uno lo hará como mejor sepa. En mi caso tengo bastante avanzada una clase para crearlo. Basicamente se crea utilizando TEXT .... ENDTEXT. Supongo que habrá formas mejores de hacerlo, pero ahora mismo con las prisas es la mejor que se me ha ocurrido. A finales de la semana que viene intentaré compartirla en el grupo por si a alguien le sirve. De todas formas las mayores dificultades que estoy encontrando es en la información que debe llevar. Por ejemplo, a parte de los códigos IBAN y BIC, también hay que incluir un identificador de acreedor. Pero sobre todo, una vez que lo tenga más o menos terminado tendré que hacer pruebas, y para eso necesitaré la colaboración de algún banco.

Un saludo,

-----------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España
-----------------------------------------------

[Miguel A.]

Hola Juan Pablo,

La idea de utilizar TEXT ENDTEXT es buena porque te permite introducir las variables entre las etiquetas de forma cómoda, pero si lo haces así, mi pregunta es cómo montas el fichero final?,

- Con cada apunte creas un fichero de texto y los adicionas todos al final?

- Vas incrementando el TEXT ENDTEXT con cada apunte, hasta formar un chorizo inmenso como decía creo que Luis?.

Yo pienso que lo idóneo sería que existiese la posibilidad de guardar lo que hay entre TEXT y ENDTEXT en una variable y que esa variable pase a ser el contenido de un campo memo al efectuar el apunte. De esta forma se compondría el XML con una sola instrucción, al tiempo que el empleo de una tabla de apuntes te permitiría hacer modificaciones, continuar con una remesa que se ha empezado a crear anteriormente, etc. Desconozco por completo si esto es posible, si alguno conoce la forma o la instrucción que haga esto: almacenar el contenido entre text endtext en una variable, sería fenomenal.

Saludos,

Miguel A.

[prga...@gmail.com]

Hola compañeros,

                            Totalmente de acuerdo en que los bancos no facilitan la labor, si consigo un formato valido para SEPA XML lo publicaré, esperemos poder aclarar este tema pronto, grácias de antemano.

[Alfonso Cobo Ortega]

Hola a todos, estoy buscando informacion sobre este asunto, y he encontrado esta pagina, que creo que os podria ser util.

http://www.iso20022.org/message_archive.page

a la mitad de la pagina, en el apartado

Third version of the Payments Initiation messages

hay unas descargas que creo que pueden ser utiles.

Un Saludo

Alfonso Cobo

[Juanpa]

Hola Miguel,

TEXT...ENDTEXT hace precisamente eso que dices. Guarda toto lo que hay entre TEXT y ENDTEXT en una variable.
Ej.:

TEXT TO MiVariable NOSHOW
....
....
ENDTEXT

La idea es que se puede llamar a un método de la clase tantas veces como apuntes se quieran hacer. Cada vez que se le llama incluirá en la variable el nuevo apunte y los anteriores.

El Jueves o el Viernes, después del fin de año, intentaré compartir la clase que estoy haciendo para que veas la idea.

Un saludo,

-----------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España
-----------------------------------------------

[Miguel A.]

Hola,

 

Fenomenal, desconocía esta opción de TEXT ENDTEXT, siendo así será bastante fácil implementar esa clase en un formulario y hacer un primer archivo experimental para intentar pasárselo a algún banco.

Seguimos avanzando!.

 

Saludos,

Miguel A.

 

El domingo, 29 de diciembre de 2013 23:15:26 UTC+1, Juanpa escribió:

Hola Miguel,

[Julian Garcia]

Tomando nota de algunas rutinas obtenidas en este mismo foro con adaptaciones realizadas por mi, asi como otras rutinas elaboradas para la obtención de determinados códigos necesarios en los nuevos cuadernos SEPA, se incluye un fichero (para renombrar con extensión .prg) con las siguientes funciones:

GENBIC()  Rutina que genera el código BIC de la entidad. Incluye 257 códigos conocidos en España. Obtenido de www.bde.es

CALCULA_IBAN() Rutina para calcular el código IBAN a partir del código CCC --VALIDO solo para ESPAÑA-. con opcion de calcular solo la parte IBAN (ES + 2 dígitos de control) o la cadena completa IBAN (24 caracteres)

CALCULA_ACREEDOR() Rutina para calcular el código ACREEDOR a partir del CIF de la entidad.

TEXTO_IBAN() Rutina para mostrar el código IBAN en papel a partir del código CCC con posibilidad de ocultar parcialmente el CCC

Todas las funciones han sido probadas. Espero que sea de utilidad.

Saludos
Julián García

[Josep FERRET MATA]

Hola Julian, Perdona, pero no entiendo el tratamiento que se le da a la letra del CIF, podrias explicarlo?, grácias por todo.

letraCIF=SUBSTR(CIF,1,1)

cAux = alltrim(str(&letraCIF))+substr(CIF,2,8)+'14'+'28'+'00'

 

 

&letraCIF, me da error

J. Ferret

2013/12/30 Julian Garcia <juliangarc...@gmail.com>

--

Salutacions,

                   Josep Ferret

           Programes Àgora, S.L.

[Miguel A.]

Hola,

Transforma la letra en el valor correspondiente, pero el problema es que está suponiendo que se trata de una sociedad porque únicamente considera que la letra puede ir al inicio y las personas tenemos un NIF con la letra al final y algunas sociedades llevan una al principio y otra al final, yo creo que por eso es mejor poner este código:

nLONGI=LEN(lcCIF)

FOR I=1 TO nLONGI

IF SUBSTR(lcCIF,I,1)$'ABCDEFGHIJKLMNOPQRSTUVWXYZ'

letraCIF=SUBSTR(lcCIF,I,1)

lcCIF=STUFF(lcCIF,I,1,str(&letraCIF))

nLONGI=LEN(lcCIF)

ENDIF

ENDFOR

cAux = lcCIF++'14'+'28'+'00'

Feliz año,

Miguel A.

[Julian Garcia]

Correcto Miguel.

El planteamiento solo es válido para sociedades con letra inicial en el CIF, como era mi caso. Con el código que propones es válido para CIF con letras tanto incial como al final.

No obstante, el bucle For ...Endfor da error porque no reemplaza correctamente el valor de las letras al estar analizando la variable lcCIF. Tambien da error en el resultado de MOD(nParte2,97) porque la cadena cAux ha aumentado de tamaño.

Paso la función CALCULA_ACREEDOR() nuevamente con las correcciones sobre las cuestiones apuntadas.

FUNCTION CALCULA_ACREEDOR(lcCIF, lcSufijo, llDControl)
**---------------------------------------------**
* Rutina para calcular el código ACREEDOR a partir del CIF de la entidad
* Parámetros:
* lcCIF = CIF de la entidad
* lcSufijo = Código sufijo de la entidad. Por defecto '000'
* llDControl = Obtener solo parte ES+los dos dígitos de control. Por defecto .F.
*-----------------------------------------------------

LOCAL nParte1 AS Integer, nResul1 AS Integer, cResul1 AS String, ;
      nParte2 AS Integer, nResul2 AS Integer, cResul2 AS String,;
      CIF       AS String,  nDigitosControl AS Integer, cDigitosControl AS String

Local llSoloDControl, letraCIF, Sufijo, i, nLetras
Sufijo      = IIF(vartype(lcSufijo)='C', lcSufijo, '000')
llDControl  = IIF(vartype(llDControl)='L', llDControl, .F.)

** Valor de cada letra para convertir el código de país a numérico
Local A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z
A = 10
B = 11
C = 12
D = 13
E = 14
F = 15
G = 16
H = 17
I = 18
J = 19
K = 20
L = 21
M = 22
N = 23
O = 24
P = 25
Q = 26
R = 27
S = 28
T = 29
U = 30
V = 31
W = 32
X = 33
Y = 34
Z = 35

if parameters()>0
    **/Eliminar guiones  y espacios en blanco en el CIF
    CIF = alltrim(STRTRAN(STRTRAN(m.lcCIF, '-', ''), ' ', ''))
endif

IF LEN(m.CIF) # 9 OR ISDIGIT(m.CIF)
    MESSAGEBOX('CIF no válido (Letra + 8 dígitos).', 0+32+0, 'CIF:'+m.lcCIF)   
    RETURN (m.CIF)
ENDIF

** Convertir las letras del país (ES) en números aplicando E = 14 ; S = 28 y la letra del CIF por su valor
** En este ejemplo añado al CIF los números correspondientes al "ES" y dos ceros al final

**/letraCIF=SUBSTR(CIF,1,1)  && Válido para CIF con solo letra inicial
**/ cAux = alltrim(str(&letraCIF))+substr(CIF,2,8)+'14'+'28'+'00'

**/ Adaptando corrección por MIGUEL A. para CIFs con mas de una letra
cAux    = CIF
nLetras = 0

FOR i=1 TO LEN(CIF)
    IF SUBSTR(CIF,I,1)$'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
        letraCIF=SUBSTR(CIF,i,1)
        cAux=STUFF(cAux,i+nLetras,1,alltrim(str(&letraCIF)))
        nLetras = nLetras+1
    ENDIF
ENDFOR

cAux = cAux+'14'+'28'+'00'

nParte1 = VAL(SUBSTR(cAux,1,8))
nResul1 = MOD(nParte1,97)
cResul1 = ALLTRIM(STR(nResul1))

nParte2 = VAL(cResul1+SUBSTR(cAux,9,LEN(cAux)-8))
nResul2 = MOD(nParte2,97)
cResul2 = ALLTRIM(STR(nResul2))

nDigitosControl = 98 - VAL(cResul2)
cDigitosControl = ALLTRIM(STR(nDigitosControl))

** Los dígitos calculados de control deben ser 2 así que si el resultado es menor de 10, añado un 0 por delante
cDigitosControl = PADL(cDigitosControl, 2, "0")

return('ES'+cDigitosControl+IIF(llDControl,'',m.Sufijo+CIF))
endfunc

Feliz Año Nuevo

[Juanpa]

Buenas,

Comparto la clase que he creado para la generación de archivos XML según la norma 19.14. Va incluido un ejemplo de como utilizarla. No está documentada ya que no tengo tiempo ahora mismo.

Está a falta de probarlo con algún banco, por lo que se puede decir que es una versión beta. En cualquier caso, espero os pueda servir y me informeis de las posibles correcciones que necesite.

Un saludo,

--------------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España

--------------------------------------------------

[Luis M.]

Gracias Juan Pablo por compartirlo. Hoy mismo me pongo a probarlo.

Saludos,

Luis Martínez.

[Jesús RA]

Gracias Juan Pablo, probamos y te decimos.

Feliz Año!!!

[Miguel A.]

Gracias Juanpa,

Probaré y te comento cómo van reaccionando los bancarios.

Saludos y que los Majos de Oriente te recompensen por ello.

Miguel A.

El viernes, 3 de enero de 2014 10:04:34 UTC+1, Juanpa escribió:

[Luis M.]

Juan Pablo,

He probado el fichero XML que genera tu aplicación en la Web de La Caixa que tiene una opción de "Validación de ficheros de prueba" y me da dos tipos de errores:

En la línea 71 y 193: Registro vacío.

En la línea 231: Registro con longitud incorrecta.

El primero se soluciona quitando una línea en blanco que queda después de la etiqueta: "</CdtrSchmeId>"

El segundo se soluciona añadiendo un CR y LF al final del archivo, después de la etiqueta: "</Document>"

He corregido estas incidencias en el fichero XML generado y entonces se valida correctamente.

Enhorabuena por tu trabajo!

Luis Martínez.

El viernes, 3 de enero de 2014 10:04:34 UTC+1, Juanpa escribió:

[Julian Garcia]

Gracias por tu trabajo.
Sin duda de grna interés.

Saludos,
Julián García

[Luis M.]

Sobre los mandatos SEPA:

He visto información contradictoria sobre si es obligatorio incluir la referencia y fecha del Mandato en el archivo de adeudos SEPA XML Esquema básico; En la guía de implantación estos campos aparecen como opcionales:

2.48 Identificación del mandato – MandateIdentification

 Definición: Referenciaúnica asignada por el acreedor para identificar inequívocamente el mandato (AT-01).

 Etiqueta XML: <MndtId>

 Ocurrencias: [0..1]

 Formato: Max35Text / MaxLength: 35, minLength: 1

2.49 Fecha de firma – DateOfSignature

 Definición: Fecha en la que el deudor firmó el mandato (AT-25).

 Etiqueta XML: <DtOfSgntr>

 Ocurrencias: [0..1]

 Formato: ISODate YYYY-MM-DD

Por otra parte, ¿alguno habéis automatizado la creación/envío de este documento de mandato para mandar a los clientes? 

Gracias y un saludo,

Luis Martínez.

[Luis M.]

Buenos días Juan Pablo,

Aparte de la validación preliminar del XML que comenté el otro día, hoy he recibido un informe extendido con algunos problemas detectados (adjunto archivo).

Saludos,

Luis Martínez.

[Francisco]

Bueno he visto que hay dos formas de adaptarse a SEPA o eso me ha parecido:

una es con fichero normal texto por ejemplo para el cuaderno 19 tenemos el 

19-14 Esquema básico

http://www.aebanca.es/cs/groups/public/documents/folletos/folleto-201305188.pdf

19-44 Esquema B2B

http://www.aebanca.es/cs/groups/public/documents/folletos/folleto-201305187.pdf

O bien el XML

Básico

http://www.aebanca.es/cs/groups/public/documents/folletos/folleto-201305190.pdf

B2B

http://www.aebanca.es/cs/groups/public/documents/folletos/folleto-201305191.pdf

No termino de entender cual se va a adoptar finalmente si el txt o el xml... ?¿?¿

Alguno lo entiende?

[Luis M.]

Actualmente sirven las 2 formas, sin embargo a partir del 1 de febrero de 2016 solamente quedará el XML.

Saludos,

Luis Martínez.

[Jesús RA]

Efectivamente, hasta el 1 de febrero de 2016 se aceptará como formato provisional un .txt plano que también difiere del que se está usando en la actualidad, por lo que ya puestos a modificar, casi todos hemos optado por migrar a la creación de un fichero .XML

Las últimas noticias que tengo de mi banco(Santander) sobre los Pain que aceptan son las siguientes:
-Para transferencias 001.001.02 y 001.001.03
-Para adeudos 008.001.02
-Para devoluciones/rechazos 002.001.03


Saludos

[Juanpa]

Buenas,

Voy a modificar la clase para evitar los saltos de línea que dan error al validar. En cuanto a los otros errores puede que sean por que los datos eran ficticios. Habría que probarlo con datos reales.

--------------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España

--------------------------------------------------

El martes, 7 de enero de 2014 13:18:25 UTC+1, Luis M. escribió:

[Francisco]

Bueno he detectado lo siguiente:

1) en la seccion <BtchBookg> debemos de incluri true o false no .t. o .f. asi pues debería de haber esto al comienzo e incluir esa cadena y no this.IndicadorApunteCuenta.

lcIndicadorApunteCuenta = IIF(this.IndicadorApunteCuenta,"True","False")

2)No tengo claro el objeto del adeudo.

Payments	PMNT
Cash Management	CAMT
Derivatives	DERV
Loans, Deposits & Syndications	LDAS
Foreign Exchange	FORX
Precious Metal	PMET
Commodities	CMDT
Trade Services	TRAD
Securities	SECU
Account Management	ACMT
Extended Domain	XTND

3) En vezde poner ES fijo podemos sacarlo del idAcreedor. en este apartado    <PstlAdr>

lcPaisAcreedor = LEFT(this.id_acreedor,2)

  

        <PstlAdr>

          <Ctry><<lcPaisAcreedor>></Ctry>

          <AdrLine><<lcDireccionPostalAcr>></AdrLine>

        </PstlAdr>

4) No se si este apartado es necesario <Ccy>EUR</Ccy> supongo que será por el tema del Reino unido que pese a ser europeos conservan su moneda.

Otra cosa que no se es si deben de haber tantas informaciones del pago C, como información de adeudo directo individual... o el apartado C agrupa de alguna forma a los D.. Según he visto agrupas por cliente y fecha vto... pero no se si eso es correcto.

pd: Sigo en ello y revisando...

[Angel Jimenez]

Hola Buenas llevo dos días rompiendome la cabeza, me han pasado un proyecto para manternerlo en visual Studio, este programa genera un fichero norma 19 en texto plano, ahora hay que hacer que genere el nuevo formato 19-14 SEPA, me podeis decir cuales son las principales diferencias al nuevo formato?? Solo es añadir la cuenta del cliente con formato IBAN ?? (esto ya lo he realizado introducciendo una función en la aplicación) , hay algún cambio mas ?? me tiene mareado el tema!! Muchas Gracias!

 

 

[Francisco]

Y más que te va a marear amigo... si relees este hilo veras que hay 4 tipos de fichero para el nuevo cuaderno 19. Dos de ellos son txt validos hasta 2016 y los otros dos XML validos hasta X. Si no te quieres liar mucho cambia los txt simplemente a la nueva norma... aunque si pal 2016 tendrás que volver a modificarlos por los xml...

una es con fichero normal texto por ejemplo para el cuaderno 19 tenemos el 

19-14 Esquema básico TXT

http://www.aebanca.es/cs/groups/public/documents/folletos/folleto-201305188.pdf

19-44 Esquema B2B TXT

http://www.aebanca.es/cs/groups/public/documents/folletos/folleto-201305187.pdf

Básico XML

http://www.aebanca.es/cs/groups/public/documents/folletos/folleto-201305190.pdf

B2B XML

http://www.aebanca.es/cs/groups/public/documents/folletos/folleto-201305191.pdf

[Luis M.]

Noticia de última hora: La Comisión Europea ha decidido este jueves conceder una prórroga extra de seis meses, hasta el 1 de agosto de 2014, para adaptarse al número de cuenta bancaria europeo. 

Leer más: Bruselas concede una prórroga de seis meses para adaptarse al número de cuenta bancaria europeo - elEconomista.es http://www.eleconomista.es/interstitial/volver/nuezene14/economia/noticias/5445091/01/14/Bruselas-concede-una-prorroga-de-seis-meses-para-adaptarse-al-numero-de-cuenta-bancaria-europeo.html#Kku8Qhi2mOghf9PR

De todas formas, ya que el tema está "caliente", mi intención es seguir con el cambio y quitármelo de encima.

Saludos,

Luis Martínez.

[Francisco]

Obviamente hay que seguir ahora que lo tenemos fresco...

[Francisco]

¿Has logrado resolver lo de los espacios?

El miércoles, 8 de enero de 2014 09:21:26 UTC+1, Juanpa escribió:

[Juanpa]

Hola Francisco,

Si he solucionado lo de los espacios. Adjunto la última versión que tengo de la clase.

De todas formas, te recuerdo que en el ejemplo que puse de como utilizarla, los datos introducidos son inventados, por tanto, puede que no te lo valide un banco. Para validarlo habría que sustituirlos por datos reales. Aun así, he logrado validarlo con éxito en la siguiente web que publicaron en otro hilo:

http://www.mobilefish.com/services/sepa_xml_validation/sepa_xml_validation.php

Un saludo,

--------------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España

--------------------------------------------------

[Francisco]

Te falta el valor de pcAvanlin he supuesto que sera algo como CHR(13)+CHR(10)

[Javier Barrera]

Muchas gracias Juan Pablo por tu esfuerzo y por compartirlo. Si no es molestia me gustaría preguntarte si tienes intención de ampliar la clase para implementar las transferencias.

Saludos,

El lunes, 13 de enero de 2014 11:35:05 UTC+1, Juanpa escribió:

[Francisco]

Bueno se ha implementado sepa para cuaderno 19 Básico, ahora faltaría el B2B. Voy a mirar como es este último he intentar implementar otra clase dentro de sepa segun el "cuaderno"... 

[Juanpa]

Efectivamente. Tengo declarado pcAvanLin como una variable pública en mi aplicación y se me pasó cambiarlo para compartirlo.

--------------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España

--------------------------------------------------

[Juanpa]

Hola Javier,

De momento lo próximo que haré será adaptarlo, como ha comentado Francisco, a la norma 19.44 B2B. Aunque no sé cuando voy a tener tiempo de hacerlo. Lo de las transferencias si algún cliente me lo pide lo tendré que hacer pero en principio no lo tengo planeado.

De todas formas una vez tenemos la idea de como crear el 19.14, el crear el 19.44 no creo que sea muy dificil.

--------------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España

--------------------------------------------------

El martes, 14 de enero de 2014 09:42:42 UTC+1, Javier Barrera escribió:

[Luis M.]

Buenas tardes Juan Pablo,

He hecho alguna prueba validando con datos reales en el servicio de La Caixa y las únicas incidencias son:

- Todas las fechas mandadas deben ser en formato AAAA-MM-DD (en el ejemplo había alguna del tipo "2014- 2- 2" y debe ser "2014-02-02").

- El campo TRUE de la etiqueta <BtchBookg>TRUE</BtchBookg> hay que pasarlo en minúsculas (<BtchBookg>true</BtchBookg>).

Saludos,

Luis Martínez.

[Juanpa]

Efectivamente Luis,

Esos cambios habría que hacerlos al utilizar la clase, es decir, cambiando el ejemplo que puse de como utilizarlo.

En cuando a la fecha, la nueva versión de la clase, dispone ahora de un método que pasándole una variable en formato fecha devuelve esa fecha en formato ISO.

Los líneas que habría que cambiar en el ejemplo quedarían de la siguiente forma:

loSEPA.IndicadorApunteCuenta = "true"

loSEPA.FechaCobro = loSEPA.DameFechaISO(ldFechaCobro)

--------------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España

--------------------------------------------------

[Francisco]

He repasado la B2B y la única diferencia que he visto es que la propiedad loSEPA.codinstrumentolocal = "B2B" hay que ponerla asi en vez de "CORE" que es para la Básica. No he visto ninguna otra diferencia a parte del apartado 2.79 de Información regulatoria <RgltryRptg> que no he visto su descripción ni en el propio pdf con lo cual supongo no se usa. Si alguno puede confirmar algun cambio más creo que esta misma clase vale tanto para CORE como para B2B cambiando eso. Por supuesto que en el B2B tenemos que poner una referencia de mandado y una firma de mandato correctas y no las que vienen por defecto.

Saludos.

[Francisco]

He visto que la función validartexto no está completamente terminada en la clase, alguno la tiene. Es por no repetir código.

[Irene Hernandez]

Hola a todos, 

he estado leyendo todo lo publicado sobre el SEPA en este grupo. Me ha parecido muy interesante.

Veo que todo esta enfocado al cuaderno 19. 

Alguien ha hecho algo del cuaderno 34 en XML.

Muchas gracias

Irene

[Francisco]

Bueno visto que nadie responde pongo aquí lo que rapidamente he realizado para salir del paso:

LPARAMETERS tcCadenaComprobar

LOCAL lcCaracteresValidos, lcCadenaLimpia, lcletra, nt

lcCaracteresValidos = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789/-?:().,‘ "

tcCadenaComprobar = CHRTRAN(UPPER(ALLT(tcCadenaComprobar)), "ÑÇ", "NC")

tcCadenaComprobar = CHRTRAN(UPPER(ALLT(tcCadenaComprobar)), "ñç", "nc")

lcCadenaLimpia=""

FOR nt=1 TO LEN(tcCadenaComprobar)

lcletra=SUBSTR(tcCadenaComprobar,nt,1) 

IF (lcletra $ lcCaracteresValidos) 

lcCadenaLimpia = lcCadenaLimpia + lcletra

ENDIF

ENDFOR

RETURN lcCadenaLimpia

[Juanpa]

Muchas gracias Francisco por completar el código.

--------------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España

--------------------------------------------------

[Jesús RA]

Por mi parte, al método "validartexto" le he modificado lo siguiente y el resto lo he dejado tal cual:

lcCadenaLimpia = CHRTRAN(UPPER(ALLT(tcCadenaComprobar)), "áéíóúüÁÉÍÓÚÜÑǺª", "aeiouuAEIOUUNC  ")

Saludos

[Juanpa]

Francisco, me he dado cuenta que al utilizar CHRTRAN no es necesario utilizar UPPER() ya que si se admiten caracteres en minúsculas. Por otro lado he visto otros caracteres que pueden ser sustituidos. El método completo podría quedar así:

LPARAMETERS tcCadenaComprobar

LOCAL lcCaracteresValidos, lcCadenaLimpia, lcletra, nt

lcCaracteresValidos = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789/-?:().,‘ "

tcCadenaComprobar =CHRTRAN(ALLT(tcCadenaComprobar), "ÑñÇçÜüÁÉÍÓÚáéíóú", "NnCcUuAEIOUaeiou")

lcCadenaLimpia=""

FOR nt=1 TO LEN(tcCadenaComprobar)

lcletra=SUBSTR(tcCadenaComprobar,nt,1) 

IF (lcletra $ lcCaracteresValidos) 

lcCadenaLimpia = lcCadenaLimpia + lcletra

ENDIF

ENDFOR

RETURN lcCadenaLimpia

--------------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España

--------------------------------------------------

El martes, 21 de enero de 2014 19:06:15 UTC+1, Francisco escribió:

[mmar...@ipamark.com]

Hola Julian,

Este código también funciona cuando el CIF tiene una letra al principio y otra al final, como ciertas entidades.

lcCIF2=''

** Convertir las letras del país (ES) en números aplicando E = 14 ; S = 28 y la letra del CIF por su valor

** En este ejemplo añado al CIF los números correspondientes al "ES" y dos ceros al final

nLONGI=LEN(lcCIF)

FOR I=1 TO nLONGI

                IF SUBSTR(lcCIF,I,1)$'ABCDEFGHIJKLMNOPQRSTUVWXYZ'

                               letraCIF=SUBSTR(lcCIF,I,1)

                               lcCIF2=lcCIF2+ALLTRIM(str(&letraCIF))

                ELSE

                               lcCIF2=lcCIF2+SUBSTR(lcCIF,I,1)

                ENDIF

ENDFOR

cAux = lcCIF2++'14'+'28'+'00'

Saludos,

Miguel A.

El miércoles, 1 de enero de 2014 23:27:13 UTC+1, Julian Garcia escribió:

Correcto Miguel.

El planteamiento solo es válido para sociedades con letra inicial en el CIF, como era mi caso. Con el código que propones es válido para CIF con letras tanto incial como al final.

No obstante, el bucle For ...Endfor da error porque no reemplaza correctamente el valor de las letras al estar analizando la variable lcCIF. Tambien da error en el resultado de MOD(nParte2,97) porque la cadena cAux ha aumentado de tamaño.

Paso la función CALCULA_ACREEDOR() nuevamente con las correcciones sobre las cuestiones apuntadas.

FUNCTION CALCULA_ACREEDOR(lcCIF, lcSufijo, llDControl)
**---------------------------------------------**
* Rutina para calcular el código ACREEDOR a partir del CIF de la entidad
* Parámetros:
* lcCIF = CIF de la entidad
* lcSufijo = Código sufijo de la entidad. Por defecto '000'
* llDControl = Obtener solo parte ES+los dos dígitos de control. Por defecto .F.
*-----------------------------------------------------

LOCAL nParte1 AS Integer, nResul1 AS Integer, cResul1 AS String, ;
      nParte2 AS Integer, nResul2 AS Integer, cResul2 AS String,;
      CIF       AS String,  nDigitosControl AS Integer, cDigitosControl AS String

Local llSoloDControl, letraCIF, Sufijo, i, nLetras
Sufijo      = IIF(vartype(lcSufijo)='C', lcSufijo, '000')
llDControl  = IIF(vartype(llDControl)='L', llDControl, .F.)

** Valor de cada letra para convertir el código de país a numérico
Local A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z
A = 10
B = 11
C = 12
D = 13
E = 14
F = 15
G = 16
H = 17
I = 18
J = 19
K = 20
L = 21
M = 22
N = 23
O = 24
P = 25
Q = 26
R = 27
S = 28
T = 29
U = 30
V = 31
W = 32
X = 33
Y = 34
Z = 35

if parameters()>0
    **/Eliminar guiones  y espacios en blanco en el CIF
    CIF = alltrim(STRTRAN(STRTRAN(m.lcCIF, '-', ''), ' ', ''))
endif

IF LEN(m.CIF) # 9 OR ISDIGIT(m.CIF)
    MESSAGEBOX('CIF no válido (Letra + 8 dígitos).', 0+32+0, 'CIF:'+m.lcCIF)   
    RETURN (m.CIF)
ENDIF

** Convertir las letras del país (ES) en números aplicando E = 14 ; S = 28 y la letra del CIF por su valor
** En este ejemplo añado al CIF los números correspondientes al "ES" y dos ceros al final

**/letraCIF=SUBSTR(CIF,1,1)  && Válido para CIF con solo letra inicial
**/ cAux = alltrim(str(&letraCIF))+substr(CIF,2,8)+'14'+'28'+'00'

**/ Adaptando corrección por MIGUEL A. para CIFs con mas de una letra
cAux    = CIF
nLetras = 0

FOR i=1 TO LEN(CIF)
    IF SUBSTR(CIF,I,1)$'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
        letraCIF=SUBSTR(CIF,i,1)
        cAux=STUFF(cAux,i+nLetras,1,alltrim(str(&letraCIF)))
        nLetras = nLetras+1
    ENDIF
ENDFOR

cAux = cAux+'14'+'28'+'00'

nParte1 = VAL(SUBSTR(cAux,1,8))
nResul1 = MOD(nParte1,97)
cResul1 = ALLTRIM(STR(nResul1))

nParte2 = VAL(cResul1+SUBSTR(cAux,9,LEN(cAux)-8))
nResul2 = MOD(nParte2,97)
cResul2 = ALLTRIM(STR(nResul2))

nDigitosControl = 98 - VAL(cResul2)
cDigitosControl = ALLTRIM(STR(nDigitosControl))

** Los dígitos calculados de control deben ser 2 así que si el resultado es menor de 10, añado un 0 por delante
cDigitosControl = PADL(cDigitosControl, 2, "0")

return('ES'+cDigitosControl+IIF(llDControl,'',m.Sufijo+CIF))
endfunc

Feliz Año Nuevo

[Paco Simarro López]

Tremendo trabajo, y tremenda solidaridad la del compañero Juan Pablo Martín Peinado.

Quiero agradecerle públicamente el que haya puesto el código de su clase a disposición  de todos nosotros.

Muchas Gracias.

Paco Simarro.

El miércoles, 13 de noviembre de 2013 19:35:16 UTC+1, Francisco Alemañ Baeza escribió:

Alguno tiene la función de paso de CCC (codigo cuenta corriente) a IBAN para la comunidad europea? Por el tema de los cuadernos nuevos

19-14 del SEPA.?

[Juanpa]

Gracias Paco, durante muchos años yo he recibido mucho más de lo que he aportado a este grupo. En este caso yo también quiero agradecer el trabajo de otros compañeros que han colaborado de una u otra forma en resolver todo este lio que tenemos con lo del SEPA.

Por citar a algunos, quiero dar las gracias a Miguel A. y Francisco Alemañ por su aportación para obtener el IBAN a partir del CCC, a Julian García por su aportación para calcular el Id del acreedor, a Luis M. y Francisco por probar y aportar correcciones a la clase que publiqué y gracias a todos los que han compartido enlaces para buscar información sobre el tema.

--------------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España

--------------------------------------------------

[Francisco]

Hay que tener en cuenta que los autónomos no tienen CIF sino que utilizan el NIF como identificador por tanto tienen la letra al final. Hay que modificar entonces dicho proceso... 

Quitando de la funcion esto: OR ISDIGIT(m.CIF)

Para este ejemplo: nif: 33005353P nos devuelve (para españa) ES8000033005353P que creo que es correcto. Pero claro hay que omitir esa comprobación sino nos devuelve cif incorrecto.

[Miguel A.]

Hola Francisco,

No sé por qué actualmente se sigue diferenciando entre CIF y NIF, cuando es lo mismo: un código que te identifica ante Hacienda.

Existen CF con una letra al principio (sociedades mercantiles), al final (Autónomos y Asociaciones( y también hay entidades (como las Ferias) que tienen una letra al principio y otra al final.

En todos los casos, o bien la letra, o bien uno de los dígitos es de control y por tanto se puede saber si un CIF es correcto o no. Desde hace años yo utilizo un código, que no sé de dónde lo he sacado, que responde a esta pregunta. Si quieres te lo paso o lo cuelgo aquí sin ningún problema, reitero que no es mío, eso sí lo he ido adaptando a los nuevos modelos que se crearon hace unos años.

Saludos y a por el viernes!!!!!!!!!!!!!

Miguel A.

[Francisco Alemañ Baeza]

Bueno he mandado la estructura del xml y me han dicho que es correcta. Ahora luego me dicen que los datos no son correctos pero curiosamente me mandan unas lineas que no tienen sentido

Paso a poner lo que informan:

Buenos días,

Tras la revisión del fichero REMESAS_SEPA.XML se comprueba que la estructura XML es correcta pero la validación de datos es incorrecta.

Les indicamos el listado de errores detectados:

- Línea 3: Registro con errores de validación de fichero plano (Validaciones AEB)  -  Tipo identificación del deudor mal informado.  

- Líneas de la 7 a la 30:  Registro con errores de validación de fichero plano (Validaciones AEB) - Tipo identificación del deudor mal informado
- Líneas de la 34 a la 36: Registro con errores de validación de fichero plano (Validaciones AEB) - Tipo identificación del deudor mal informado.  

No le veo sentido alguno a dichas anomalias teniendo en cuenta el fichero que he pasado...Dado que en esas lineas que me indican hay estructura y no datos. Tampoco se pq dicen validación de fichero flano cuando no es un txt sino un xml... en fin creo que los bancos no saben lo que están haciendo...

¿Alguno tiene noticias de validaciones correctas?

[siste...@gmail.com]

Hoy he enviado a mi banco una remesa en formato XML, ja os diré el resultado de la validación

[Juanpa]

Hola Francisco,

En mi empresa ya hemos enviado varios ficheros con el nuevo formato y ha funcionado correctamente. La única diferencia es que ahora tardan más días en hacer el ingreso. También he actualizado a varios clientes y hasta ahora no me han informado de ninguna incidencia.

--------------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España

--------------------------------------------------

[Luis M.]

Por lo que yo estoy viendo, los bancos andan bastante desbordados con este tema.

Me ha ocurrido que mando una remesa a un servicio de Validación de ficheros (en concreto de La Caixa) y me dice que es correcto, sin embargo mando la remesa "en real" y me viene devuelta.

También he observado lo que comenta Juan Pablo, que tardan mas en ingresar la remesa.

Saludos,

Luis Martínez.

El jueves, 30 de enero de 2014 18:33:58 UTC+1, Francisco Alemañ Baeza escribió:

[Francisco Alemañ Baeza]

Lo más gracioso es que ponen "(Validaciones AEB)" y la verdad no tiene nada que ver con ningun AEB. NO SE ENTERAN ESTOS DE LA MISA LA MITAD. 

Que mal que vamos... 

[Jesús RA]

Yo hice la validación contra el Santander y el primer mensaje que me enviaron era muy similiar a ese, con poco detalle de los errores y haciendo referencia a un fichero de texto plano.
Les solicité más detalles de los errores y me contestaros con el error en concreto que habían encontrado.

Creo tal y como dice otro compañero, que los bancos estan tan desbordados.

El jueves, 30 de enero de 2014 18:33:58 UTC+1, Francisco Alemañ Baeza escribió:

[Francisco Alemañ Baeza]

Se está produciendo el caso que los bancos y cajas TODOS han optado por la opción del formato AEB 19.14 o 19.44 valido solo hasta el 2016 y han pasado olimpicamente del xml. El resultado es la imposibilidad por parte la aplicación que genera xml de poder entregar en este formato. No se si os ha pasado pero parece que no entienden la diferencia entre los AEB de transicion y los xml definitivos. En fin... que mal que vamos....

[Francisco]

Tengo la detección de este error en la clase:

En relación a su consulta sobre los errores encontrados en el fichero RESEMSAS_SEPA.XML, indicarle que es debido a que no está informando del ID de los deudores.

 

Según la norma SEPA, la estructura <Cdtr> tiene que indicar la etiqueta <Id> de forma obligatoria. Dentro de ella debe ir el NIF o CIF del deudor.

 

Su estructura en los errores es la siguiente:

 

- <Dbtr>

        <Nm>XXXXXXXXXXXXXXXXXXX</Nm>

-        <Id>

-          <OrgId>

                 <BICOrBEI>BCOEESMM005</BICOrBEI>

    </OrgId>

   </Id>

</Dbtr>

 

Siendo la estructura correcta:

 

<Dbtr>

        <Nm>XXXXXXXXXXXXXXXXXXXXXX</Nm>

-        <Id>

-          <OrgId>

                   <BICOrBEI>BCOEESMM005</BICOrBEI>

                   <Othr>

                       <Id>CIF O NIF DEL DEUDOR</Id>

                   </Othr>

    </OrgId>

   </Id>

</Dbtr>

 

Estoy corrigiendo la clase pero para los demas... ya sabeis.... 

[Jesús RA]

Acabo de recibir contestación del Santander a una nueva prueba que envié la semana pasada.
Me indican que el campo BIC y BICOrBEI están mal informados al ir vacíos, por lo que tenemos un pequeño problema, ya que en mi base de datos he encontrado datos de CCC con entidades que ya no existen.
Evidentemente, se puede controlar y en caso de no tener el BIC de la entidad a la que se envía el adeudo, informar antes de incluir el adeudo en el fichero.
Mi pregunta es, ¿el BIC y BICOrBEI del adeudo son campos obligatorios? En caso de no serlo, si no hay dato ¿se incluyen las etiquetas vacías o directamente no se incluyen?

        <DbtrAgt>
          <FinInstnId>
             <BIC></BIC>
          </FinInstnId>
        </DbtrAgt>
        <Dbtr>
          <Nm>JUAN PRUEBA PRUEBA</Nm>
          <Id>
             <OrgId>
                 <BICOrBEI></BICOrBEI>
                 <Othr>
                     <Id>12345678X</Id>
                 </Othr>
             </OrgId>
          </Id>
        </Dbtr>


Saludos a todos

[siste...@gmail.com]

El Banco de Santander me ha comunicado:

Si la remesa se hace en formato xml, el cliente debe crear obligatoriamente una etiqueta identificativa para ubicar el campo BIC, aunque puede informar en la misma un textual que sea o “NOTPROVIDED” o “NOTPROVI”. (En función de si en su base de datos tiene alimentada esa información con ocho u once posiciones).

El dimarts 4 de febrer de 2014 17:30:07 UTC+1, Jesús RA va escriure:

[Miguel A.]

Hola,

Un par de apuntes, que como esto lo han prorrogado hasta agosto, me da a mí la impresión de que todos hemos optado por seguir con "virgencita, virgencita que quede como estoy" y verdaderamente no hemos empezado a enviar adeudos con este sistema.

La primera es: ¿Cómo vais? Habéis conseguido presentar algún adeudo, el formato final cuál es, con qué banco... Contar vuestras experiencias por favor.

La segunda es referente a un código para calcular el acreedor que habíamos estado manejando creo que Francisco Alemán y yo también había hecho algún apunte, y es que hay un error grave en él. En el bucle FOR ENDFOR se emplea la variable "I" (como siempre), pues... en este caso también es una variable local de la letra "I", así que si por ejemplo el NIF de un autónomo lleva esta letra, el valor que está tomando es el del bucle anterior, tenéis que cambiar el nombre de esa variable por otro cualquiera, que tenga al menos 2 letras.

Ya contaréis...

Saludos,

Miguel A. Martínez

[Julian Garcia]

Buenas noches, Miguel

El problema que comentas no es posible porque no puede existir un NIF terminado en "I" o CIF que empiece por "I".

Para evitar errores de de composición de NIF o CIF, tiempo atras adapté la función de cáculo del Acreedor añadiendo comprobaciones si trata de CIF o NIF correcto, incluso de NIF de extranjeros.

Paso dicha función adaptada para que la pruebes.

Lo que no hace la función es calcular las letras correspondientes de NIF/CIF. Esa tarea es para otra función.

Saludos
Julián García

[Miguel A.]

Hola Julian,

Pues te acabas de cargar a la Universidad de Oviedo, por ejemplo: http://sgcrue.uniovi.es/inscripcion, si que hay algún NIF con una letra "I" al final.

Y, no nos has contado tu experiencia. ¿Has conseguido presentar algún adeudo sepa?

Saludos,

Miguel

[Julian Garcia]

Pues algo no cuadra:

http://www.boe.es/boe/dias/2008/02/26/pdfs/A11374-11376.pdf
http://es.wikipedia.org/wiki/C%C3%B3digo_de_identificaci%C3%B3n_fiscal

En cuanto a presentar adeudos SEPA, no he tenido problemas tanto en transferencias (C34.14) cómo adedudos directos (C19.14), eso si, en fichero plano (txt).
Aún no he probado en XML.

Saludos
Julián García

[Luis M.]

Buenos días,

Mi experiencia es la siguiente:

- No he tenido problemas con transferencias SEPA XML.

- Los adeudos SEPA XML están dando muchos problemas, hay algún banco que admite el formato en texto plano pero no en XML, otros bancos que  lo admiten pero dan errores al validar el archivo, y sino, algunos recibos vienen devueltos...

- Estos bancos están optando por seguir aceptando la Norma 19 provisionalmente.

Yo creo que hasta dentro de un tiempo el sistema no va a funcionar correctamente.

Saludos,

Luis Martínez.

[Jorge Rodes]

Hola a todos,

Estoy intentando hacer mediante XML la conversión de ficheros norma 19 según SEPA.

El problema con el que me encuentro, es en el cálculo del BIC/SWIFT  (más arriba se pregunta si ésto es obligatorio... yo tampoco lo tengo claro, lo dejaré en NOTPROVIDED como he leído en este hilo tambien)

alguien conoce de alguna función que saque el bic a partir del iban? se que no se puede calcular, y cada entidad tiene el suyo, pero es por no preguntar a 20mil personas aver si me dan el bic de su banco.. ;)

saludos a todos 

[Miguel A.]

Hola,

El BIC tienes que sacarlo de una BD en la que estén todos los bancos, si no la tienes creo que en este hilo hay una y sino dímelo y te la envío por email.

Del IBAN puedes sacar el BIC, porque la entidad está en las posiciones 5-8 y la entidad también puedes tenerla en esa tabla, yo al menos la tengo porque era lo que se usaba antes para determinar el nombre del banco.

Supongo que la mayoría del CCC sacó el IBAN y el BIC y no se lo pidió a los clientes porque es un auténtico lío.

Saludos,

Miguel A.

[Francisco]

Nosotros tambien hemos optado por el 19.14 plano txt formato AEB porque el Core o Basico sepa xml no se enteran ni ellos.

Saludos.

[Juanpa]

Pues nosotros estamos utilizando el formato Core XML con el Sabadell y hasta ahora no hay problemas.

Próximamente lo probaremos también con el formato B2B. Ya contaré como ha ido.

--------------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España

--------------------------------------------------

[Luis M.]

¿Nos puedes comentar las diferencias en el formato del  B2B con el CORE XML?

Gracias y un saludo,

Luis Martínez.

[Miguel A.]

Hola JuanPa,

Pues qué se sepa, tú has sido el único que ha conseguido presentar algo en formato XML. ¿Solo lo has hecho con el Sabadell?

Sería de agradecer que volvieras a colgar tu clase con las modificaciones finales, esas que te han permitido hacerlo en ese banco, por que me da la impresión de que los demás, entre los problemas que tienen los bancos y los nuestros, nadie ha conseguido presentar aún adeudos en formato XML.

Saludos,

Miguel A.

El miércoles, 19 de febrero de 2014 13:37:56 UTC+1, Juanpa escribió: