Adeudos Directos SEPA en euros Esquema B2B

[Manuel Aranda]

Gracias a Manuel por modificar la función usando XML. Esto nos ayudará a profundizar en esta clase.
Y también gracias a Joaquín por el enlace al programa. Sólo lo he mirado por encima pero creo que será suficiente para generar un recibo y mirarle las "tripas" para ver _.

[FiveWiDi]

Manuel,

Respecto a las órdenes de domiciliación tanto CORE como B2B, si no estoy equivocado la normativa SEPA nos obliga a tener en el documento todos los redactados en el idioma oficial del pais y en inglés.
A ver si alguno de los presentes lo ha entendido como yo.

Supongo que por eso el modelo oficial tiene 2 idiomas.

Gracias,

[Manuel Aranda]

Carlos, así es. Lo he comprobado en la documentación del Sabadell y lo dice claro:

"El texto debe aparecer, al menos en una de las lenguas oficiales del país del deudor, así como en inglés"

Así que habrá que descartar el modelo modificado y usar el oficial.

[mastintin]

Para arreglar el tema de usar ISO en vez UTF-8 no he encontrado información por ningún lado . De momento queda resuelto con "un parche" no muy ortodoxo pero al ser en un archivo usado "temporalmente" no tiene una importancia "vital" y cumple su cometido .

Code: Select all

local oDoc := mxmlNewElement( oXml, "xfdf" )
local oFields , xDato

mxmlElementSetAttr( oXml, "encoding", 'ISO-8859-1' )  // añadido mientras se encuentra mejor solución por compatibilidad .

.......

 

[elvira]

Hola,

Esto quizás sea de utilidad:
http://www.sepaesp.es/f/websepa/seccion ... anoles.pdf

[lucasdebeltran]

Hola,

Aquí hay un conversor online:
http://www.sepaeditor.com/es/Conversion ... A-Xml.html

[FiveWiDi]

Hola a todos,

Tengo una maldita duda sobre como debe ser la identificación del acreedor en los adeudos directos SEPA.

Por un lado en la página 3 del cuaderno AEB 19-14 de noviembre-2012, se dice que la identificación debe ser del tipo:
ES99888AAAAAAAAAAAAA.. (hasta 35 caracteres en total), en donde 888 vendrían a ser el sufijo que hasta ahora se está utilizando.

Por otro lado en ese mismo cuaderno Anexo VII página 67 se indica que las reglas de migración de adeudos españoles para ese mismo dato establecen que debe ser NIF-SUFIJO:
ES99AAAAAAA888.... (hasta 35 caracteres en total).

Donde meteran ustedes el sufijo en la identificación de acreedor?

Perdonen la cuestión por no ser propia de FiveWin pero, como el hilo ha dado tanto de si...

[Manuel Valdenebro]

Tengo una maldita duda sobre como debe ser la identificación del acreedor en los adeudos directos SEPA.

La identificación del acreedor (AT-02) con un máximo de 35 caracteres, debe tener la siguiente estructura:

AA codigo del pais ("ES" para España)
DD dígito de control (a calcular segun mod-97-10)
SSS sufijo acreedor (normalmente 000)
NNNNNNNNN (nif del acreedor)

y hasta 35 caracteres si quieres añadirle algo mas.

[Manuel Valdenebro]

            if(CC_iban<10){
            CC_iban = "0" + CC_iban;
            }

Mastintin,

Sólo te falta incluir el IF que te marcó que sucede cuando al calcular el digito de control, tiene solo un dígito. Por lo demás, coincide con el código que uso y que está comprobado, salvo que yo incluyo la variable PAIS, para poder adeudar recibos a otros paises distinto que ESPAÑA.

Tambien son importantes convertir la cadena IBAN a numérico, porque sino, al dividir por 97, daría error e incluir los INT, porque en caso contrario, al sumar las cadenas, Harbour incluye el punto decimal y los decimales por defecto.

Code: Select all

FUNCTION fIban( cPais, cBanco, cSucursal, cDC, cCuenta)
local nIban, cIban, nMod, nContador, cPais2:=''

// comprueba ccc es correcto
IF !CCC (cBanco, cSucursal, cDC, cCuenta)
   MsgInfo ("CCC incorrecto.")
   // devuelve cadena vacia por error CCC
   RETURN ' '
ENDIF           
    
  FOR ncontador = 1 TO 2
      IF ASC(SUBSTR(cPais, ncontador, 1)) >= 65
           cPais2 += STR( (ASC(UPPER(SUBSTR(cPais, ncontador, 1)))-55), 2, 0)
       ELSE
            cPais2 += SUBSTR(cPais, ncontador, 1)
      ENDIF
  NEXT  

  cIban := cBanco + cSucursal
  nMod := INT ( VAL(cIban) % 97)
  cIban := LTRIM(STR(nMod,3,0))+cDC+SUBS(cCuenta,1,2)
  nMod := INT ( VAL(cIban) % 97)
  cIban := LTRIM(STR(nMod,3,0))+SUBS(cCuenta,3) + cPais2 + "00"
  nMod := INT ( VAL(cIban) % 97 )
  nIban := INT ( 98 - ( VAL(cIban) % 97) )

  return cPais + STRZERO( nIban, 2)+cBanco+cSucursal+cDC+cCuenta
 

[elvira]

Querido Manuel,

¿Has conseguido hacer funcionar SEPA norma 19?.

Muy agradecida

[FiveWiDi]

Tengo una maldita duda sobre como debe ser la identificación del acreedor en los adeudos directos SEPA.

La identificación del acreedor (AT-02) con un máximo de 35 caracteres, debe tener la siguiente estructura:

AA codigo del pais ("ES" para España)
DD dígito de control (a calcular segun mod-97-10)
SSS sufijo acreedor (normalmente 000)
NNNNNNNNN (nif del acreedor)

y hasta 35 caracteres si quieres añadirle algo mas.

Gracias,
Así lo tengo ahora.

[mastintin]

Referente al tema de Fusionar el formulario de las Ordenes con los datos de nuestros clientes.
Mediante un xml y un programa ( exe) externo , tiene la ventaja de no necesitar el acrobat Profesional , pero para los que dispongan de el puede que sea mas facil usar automatizacion ole y prescindir tanto del archivo xml intermedio como del programa para fusionar los datos y hacerlo directamente .
Pongo un codigo resumido que funciona bien en mi ordenador .

Code: Select all

FUNCTION  FusionaDatos()

   LOCAL ScanOK
   LOCAL oApp
   LOCAL oAVDoc, okAVD
   LOCAL oPDDoc
   LOCAL oForm,oFields,ofield,cfield
   LOCAL cPath := "c:\SEPA\ordenes\sepa2.pdf"
   LOCAL i, nLen

    oApp := CreateObject( "AcroExch.App" )
    oAVDoc := CreateObject("AcroExch.AVDoc")
    oKAVD = oAVDoc:Open(cPath, "sepa2.pdf")
    pausa( oKAVD )
    oForm:= CreateObject("AFormAut.App")

    oFields = oForm:fields()
    nLen := oFields:Count()
    pausa(nLen)

    For Each oField In oFields
        cField:=  oField:Name()
        If cField == "c2"
           oField:Value:= "NIF de la empresa"
        ELSEIF cField == "c32"
           oField:Value:= "Nombre de la empresa"
        ELSEIF cField == "c33"
           oField:Value:= "Direccion de la empresa"

        ......  // resto de _ arrellenar

        endif
    Next Field
    oPDDoc := createobject("AcroExch.PDDoc")
    oPDDoc := oAvDoc:GetPDDoc()
    oPDDoc:Save(1, "c:\SEPA\ordenes\ordenfinal.pdf")
    oPDDoc:Close()
    oPDDoc := nil
    oAVDoc:BringToFront()
    oAVDoc:Maximize(1)

  //

RETURN nil


 

[Manuel Valdenebro]

Querido Manuel,

¿Has conseguido hacer funcionar SEPA norma 19?.

Si, a falta de probarlo con remesas reales en el banco.

El diseño del archivo no es complicado. Viene muy detallado en la información del SEPA. Lo complicado es _ que hay que realizar en la aplicación (en la mia) para adaptar los datos del acreedor y deudores, para que funcionen automaticamente con el nuevo formato y sobre todo, el tema de los mandatos (RCUR, FRST, FNAL) y _ en las futuras domiciliaciones.

¿Tu como lo llevas?

[FiveWiDi]

Hola a todos,

Os comento mi experiencia (poca de momento).
El Banco de Sabadell (desconozco si es por definición del cuaderno 19-14, Básico en Txt), no acepta en un mismo fichero para el mismo deudor _ con la misma referencia, ni tan siquiera en diferentes remesas del mismo acreedor con diferente fecha cargo; no me lo puedo creer. Por tanto a modificar programa. Como _, vamos 'pa tras'.
He tenido que incorporar validación de _ ya sea del nombre del acreedor, deudor, u otros posibles textos, ya que por ejemplo el arterisco no está permitido según la definición del cuaderno; seguimos yendo 'pa tras'.
Cuando la aplicación de internet del Banc Sabadell funciona (dudo que funcione siempre, al menos para SEPA), te permite validar el fichero antes de enviarlo definitivamente; al final volveremos a remesar en papel... 'vaya tela'.
Si veo algo más que sea curioso lo comento.

AÑADO.
En BS la fecha de cargo de los adeudos no puede ser anterior a la fecha de creación del fichero. Bien, no se porque lo han definido así, para mi creo que es complicarle la vida al que gestiona recibos de asociaciones o clubes o por el estilo, en donde la fecha de 'vencimiento' tiene un valor relativo. Ala, a modificar la rutina para otra 'parida'.

[Manuel Valdenebro]

1)He tenido que incorporar validación de _ ya sea del nombre del acreedor, deudor, u otros posibles textos, ya que por ejemplo el arterisco no está permitido según la definición del cuaderno; seguimos yendo 'pa tras'.
2)En BS la fecha de cargo de los adeudos no puede ser anterior a la fecha de creación del fichero. Bien, no se porque lo han definido así, para mi creo que es complicarle la vida al que gestiona recibos de asociaciones o clubes o por el estilo, en donde la fecha de 'vencimiento' tiene un valor relativo.

1) No sólo el asterisco. Para los españoles la Ñ y la Ç y en las zonas turísticas, todos los extranjeros con caracteres especiales. Pero aunque habrá que verlo, yo creo que el sistema se va a tragar todos _. Lo que puede ocurrir es que la persona que se llama CAÑO aparezca en el recibo como CANO o CA%O.
2) Según las normas del SEPA-CORE, tiene que haber, al menos, cuatro dias desde la fecha de creación del recibo (y envio al banco) hasta la fecha de cargo/cobro (fecha en la que el banco presentará a las otras entidades los recibos al cobro). Según las normas de emigración españolas, algunas entidades españolas bajaran de cuatro a tres dias este plazo.
Esto ya existía en la norma del CSB-19 anterior. No le veo la complicación ya que la fecha de confección del fichero y la fecha de cargo son constantes en el archivo. Es tan fácil como hacer fConfeccion=DTOS(DATE()) y fCargo = DTOS ( DATE()+4)), independientemente que el recibo sea del año catapún. Otra cosa es si hay vencimientos futuros que obliga a hacer bloques por cada fecha