cancel
Showing results for 
Search instead for 
Did you mean: 

SEPA : Pago de nómina

former_member431450
Participant
0 Kudos

Buenas tardes.

De cara a la próxima implantación obligatoria de SEPA (Single Euro Payments Area), a partir del 01/02/2014, quisíéramos por favor saber cómo se va a tratar el pago de nómina (de forma estándar) si se utiliza la herramienta PMW, para obtener ficheros en formato :

Cuaderno bancario 34.14 (Fichero plano) y Ordenes de formato ISO 20022 (XML).

Es decir, se van a seguir utilizando PC00_M04_CDTA para la identificación y PC00_M04_FFOT para emitir la transferencia, adaptándolas a SEPA, o ¿van a ser nuevas transacciones?. ¿Cambiarán los procesos de pago por transferencia, de la nómina?.

Agradecemos cualquier información al respecto.

Saludos.

Accepted Solutions (0)

Answers (11)

Answers (11)

0 Kudos

Hola Javier

Aquí, en la Diputación de Barcelona tenemos desde años un desarrollo especial para las retenciones judiciales (como muchos otros).

Con la transacción FBPM estamos utilizando el esquema estandard CGI_XML_CT

El identificador del expediente de la retención lo estamos grabando en el campo REGUP-SGTXT (es un programa Z elaborado para que coja las retenciones y genere las entradas de las tablas REGU*, con lo que no se si en el estandard funciona igual).

con ello, nos aparece como.

- <CdtrAcct>

- <Id>

<IBAN>ESXXXXXXXXXXXXXXXXXXXXXX</IBAN>

</Id>

</CdtrAcct>

- <RmtInf>

<Ustrd>UES 00000000-X.X.XXXXXX-NIF:XXXX</Ustrd>

</RmtInf>

</CdtTrfTxInf>

-
yEspero que te pueda servir de ayuda.


Cordialmente
y


Ivaneee
Participant
0 Kudos

Una duda!

Si en la parametrización de la V_T77DME_PCD_WT, tengo un concepto definido como OTHR (un pago de una cuota sindical), al generar el fichero XML, a nivel de cabecera me dice:

Esto es así? Digamos que al haber otro concepto (además de la propia transferencia de la nómina que va por el /559) que se mete en la BT, al estar definido como OTHR, ya me marca el XML como OTHR y en las lineas del pago de la nómina, ya no aparece ni SALA ni OTHR.

Un saludo!

S0005892775
Explorer
0 Kudos

Buenas tardes,

Otra duda, en la tabla V_T77DME_PCD_WT, los posibles valores para el PurposeCode son PENS, SALA y espacio en blanco.

¿Se pueden definir otros valores? Como dice Iván, ¿como hay que parametrizar los conceptos adicionales que se meten en la BT como cuotas sindicales, embargos, pensión de alimentos, bonus, etc?

Muchas gracias y un saludo, David.


Ivaneee
Participant
0 Kudos

Finalmente vamos a procesar el pago por separado, por un lado todos los conceptos que generan SALA, y por otro lado los que generan OTHR. Y ningún problema así.

Un saludo!

S0005892775
Explorer
0 Kudos

Buenas tardes,

¿Alguno de vosotros a tenido que incluir el campo ZWECK (Destino de utilización p.transferencias) de los infotipo 9 y 11 en el xml de SEPA?

Si es así, ¿como lo habéis hecho?

Muchas gracias y un saludo, David.

Former Member
0 Kudos

Buenas tardes,

Nosotros tenemos el mismo problema pero con el ZWECK del infotipo 0887

En este campo informabamos el nº de expediente en los embargos.

¿Ha cambiado ahora el campo donde se debe informar el nº de expediente?

¿En el XML de SEPA donde debería aparecer este nº de expediente?

Muchas gracias.

Former Member
0 Kudos

Buenas tardes.

Efectivamente es un comportamiento estándar. El campo destino de utilización del infotipo 0887 (P0887-ZWECK), si viene informado, se imprimirá (como bien dice José Domingo) en el fichero de transferencia en la etiqueta <RmtInf><Ustrd>EXP.28211000045XXX</Ustrd></RmtInf>. Lo único que hay que parametrizar a través de la transacción OBPM2 el destino de utilización asignado a nuestra via de pago (trans.FBZP), y marcar "Txt.segm." con el tipo 1 y nº de línea 1.

Un saludo.

Former Member
0 Kudos

Muchisimas gracias. Además de la OBPM2 que no teniamos el SGTXT, también tenía marcado  "Info transferencia estructur." en la transacción FBPM en la variante de selección. Desmarcandolo ya aparece.

Un saludo

former_member431450
Participant
0 Kudos

Hola, José Miguel.

¿Se puede generalizar la solución en función del tipo de pago?.

Es decir, que el concepto sea variable en función de si es pago de nómina, retención judicial (aquí sería el destino de utilización), cuotas sindicales, pago a ONG, etc.

Muchas gracias y un saludo.

Former Member
0 Kudos

Hola Eduardo.

No se me ocurre cómo se podría hacer. El campo REGUP-SGTXT es informado desde el

programa de marcado RPCDTAE0, construido a partir de los símbolos de texto definidos en

el propio programa, además del periodo, número de personal, etc, o el destino de

utilización definido en el infotipo (p.ej. 0887). La decisión de tomar un texto u otro

se parametriza en la tabla T503, dependiendo de factores como el área de personal o

subdivisión. El único contenido variable del árbol que conozco, que dependa del concepto de nómina de pago, es el código de propuesta y la categoría de propuesta (SALA, PENS...),

parametrizable en la vista V_T77DME_PCD_WT. No sé si a partir de este campo, y

modificando el árbol, se podría adaptar la referencia de la transferencia.

Un saludo.

Former Member
0 Kudos

Hola,

¿Alguien sabe si es obligatorio informar el BIC/SWIFT en los ficheros de  transferencias SEPA? (Adeudos clientes, Transfencia Proveedores, Empleados).

El banco nos indica que no es obligatorio informarlo en los ficheros de transferencias, pero me surgen dudas.... en proveedores podría ser que no sea necesario, pero en adeudos de clientes por el tema de mandato ya no lo tengo tan claro,  ya que Sap nos obliga a informar el BIC/SWIFT en la creación de mandatos.

Todas las pruebas que hemos realizado con los bancos han sido con el BIC informado y han sido OK, (Transferencias a proveedores, empleados y Deudores), ya estamos preparados para entrar en SEPA, pero si no es necesario informar el BIC/SWIFT me gustaría suprimirlo por el coste de mantenimiento de datos.

Alguien me pueda dar luz sobre la obligatoriedad o no del SWIFT/BIC en los ficheros de transferencias así  como en el mantenimiento de datos maestros (Proveedores y Deudores).

Un saludo y gracias de antemano.

Jabi.

quuiquui
Explorer
0 Kudos

Buenos días Javier;

por lo que se indicaba en la documentación del SEPA, el SWIFT/BIC parecía un dato necesario.

Has preguntado a tu banco porque te indica que no lo es.

Nosotros hemos generado con el formato CGI_XML_CT el fichero y al enviárselo al Banco nos indican que tiene un error.

<Description>The element 'Tp' in namespace 'urn:iso:std:iso:20022:tech:xsd:pain.001.001.03' has incomplete content. List of possible elements expected: 'Cd, Prtry' in namespace 'urn:iso:std:iso:20022:tech:xsd:pain.001.001.03'.</Description>

Alguien ha tenido un error parecido o sabe como podriamos solucionarlo.

Gracias.

un saludo,

Mónica.

Former Member
0 Kudos

Hola, tengo el mismo error:

XML Validation Error

cvc-complex-type.2.4.b: The content of element 'Tp' is not complete. One of '{"urn:iso:std:iso:20022:tech:xsd:pain.001.001.03":Cd, "urn:iso:std:iso:20022:tech:xsd:pain.001.001.03":Prtry}' is expected.


Por favor si sabes el motivo y cómo corregirlo te estaré agradecido.

quuiquui
Explorer
0 Kudos

Hola Fco. Javier:

mira primero si tienes el ultimo CGI_XML_CT que ha sacado SAP en las notas. Y también mira en la variante que tengas introducido el ES dentro de los parametros, tal y como se indicaba en la parametrización del formato CGI.

Un saludo,

Mónica

Former Member
0 Kudos

Hola Mónica!,

Tengo hecho un Z del CGI_XML_CT ya que tuve que adaptar alguna etiqueta. En el programa SAPFPAYM que genera el fichero tengo asignado como formato de medio de pago mi ZCGI_XML_CT y en los parámetros formato el tick "Info transferencia estructur." y código iso "ES", nada más.

La versión CGI_XML_CT que tengo instalada no se cual es, está modificada a 28.11.2013 pero no se a qué versión corresponde.

Si me puedes echar una manita.....

Gracias.

quuiquui
Explorer
0 Kudos

Hola Francisco;

la nota que te indicaba es la 1961687, yo creo que es la última que ha salido. Espero que con eso sea suficiente.

Un saludo,

Mónica.

Former Member
0 Kudos

Buenos dias

Estamos ahora validando los ficheros y me da el mismo error que comentabas:

content of element 'Tp' is not complete. One of '{"urn:iso:std:iso:20022:tech:xsd:pain.001.001.03":Cd, "urn:iso:std:iso:20022:tech:xsd:pain.001.001.03":Prtry}' is expected.

Tengo el campo ES el el formulario ZCGI_XML_CT informado y la verdad que estoy perdida

Muchas gracias

Former Member
0 Kudos

Apliqué una o dos notas. Ahora no recuerdo cuáles, pero una de ellas tenía un adjunto con la estructura del CGI_XML_CT, en cuanto apliqué la nota y subí el nuevo formato se solucionó el problema.

Ivaneee
Participant
0 Kudos

Buenas a todos,

Alguien me puede explicar como solventar este error?

Me dice "Se crearon demasiados medios de pago para este grupo de pagos" al lanzar el report SAPFPAYM.

Primeramente he lanzado, y el banco pagador no tenía el swift. Lo he corregido, he vuelto a lanzar el report y ya me sale el error que os indico.

Mediante la FDTA he borrado la ejecución realizada, he vuelto a lanzar SAPFPAYM y lo mismo.

Como puedo solventar esto?

Muchas gracias.

quuiquui
Explorer
0 Kudos

Buenos días Ivan;

me sale el mismo mensaje pero como warning, así que no le he dado demasiada importancia. ¿A tí te da un error?.

He encontrado una pagina para validar el formato CGI_XML. Os la paso por si puede servir:

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

Un saludo,

Mónica.

Ivaneee
Participant
0 Kudos

Correcto, me he expresado mal. Me sale warning también.

lucia_iturbe
Active Participant
0 Kudos

Hola Ivan:

En el area de SAP ERP Financials hay unos cuantos hilos sobre este mensaje de error. Por ejemplo

http://scn.sap.com/thread/2122811

Un saludo, Lucía

JohnWick
Active Participant
0 Kudos

Hola parece que hay novedades en este sentido:

BRUSELAS, 9 Ene. (EUROPA PRESS) -

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. Bruselas ha admitido que si se aplica el plazo original del 1 de febrero podría haber problemas de bloqueo de pagos para consumidores y empresas debido a los retrasos en la transición hacia el nuevo formato que establece la Zona Única de Pagos en Euros (SEPA, por sus siglas en inglés).

http://www.europapress.es/economia/noticia-bruselas-prorroga-plazo-adaptarse-numero-cuenta-bancaria-...

Former Member
0 Kudos

Igual no es el sitio adecuado para la pregunta, pero no encuentro otro...

Estoy programando un generador de archivos segun normativa SEPA, para recibos que antes seguian la Norma 19. El caso es que hasta ahora podía poner importes negativos en los conceptos (abonos, devoluciones, etcc.) junto con los positivos (importe de los productos, o servicios). Pero no veo com poner importes negativos en formato SEPA, o quizás no he entendido bién como se hace.

De todas maneras si alguien tiene alguna idea me sacaría del pozo de la ignorancia.

Gracias

Former Member
0 Kudos

Hola Buenos días,

Yo tengo un error al ejecutar el programa SAPFPAYM, al ejecutar el pago para generar el XML me da el error 'BFIBL02159 Para el formato SEPA_CT no se ha creado ningún medio de pago para el grupo de pagos 0'

He revisado la parametrización con otro entorno donde si funciona, y están iguales.

Me podríais dar alguna horientazación??

Muchas gracias

David Hernández

Former Member
0 Kudos

Hola,

revisa la tabla REGUH de pagos, posiblemente no concuerda la clave (identificador + fecha) con tu petición.

saludos, Reyes

Former Member
0 Kudos

Buenos días,

En el fichero XML que genera el formato SEPA_CT, necesitaria que viajara en la etiqueta ReqdExctnDt la fecha que yo estableciese (sin seguir ningún patrón) y no la de la ejecución de la identificación de transferencias, que es la que me coge por defecto.

Por ejemplo si yo mediante el report RPCDTAE0 identifico transferencias a fecha de hoy 18.12.2013 pero no quiero que se abone hasta el 20.12.2013, no encuentro modo de que el report SAPFPAYM me permite modificar ese dato.

En el fichero xml esa etiqueta viaja así <ReqdExctnDt>2013-12-18</ReqdExctnDt>

¿podeis orientarme alguna manera de contemplarlo sin salirme del estandar?

Gracias

Elia

juan_garaymoral
Explorer
0 Kudos

Buenos días, Elia.

Nosotros lo que hemos hecho, ha sido crear una tabla Z para alimentar mes a mes la fecha de pago y en el enhancement HRPAYES_BANK_TRANSFER asignársela al "ct_seth-zaldt".

Espero que esta información te sirva.

Saludos,

Juan.

0 Kudos

Buenos días, en mi empresa se genera un único identificador de pago para todos los empleados y hasta ahora, a partir de un report de cliente, realizábamos una llamada al RFFOES para cada combinación sociedad pagadora + sociedad emisora existente, creando tanto ficheros N34 como sociedades pagadoras+emisoras tenemos.

Ahora, con el nuevo report  SAPFPAYM nos interesaría hace algo parecido, utilizando como filtro los campos Sociedad Pagadora y Sociedad Emisora de Delimitaciones opcionales, pero tenemos el problema de la pantalla “Selección Grupos pago”, que siempre saca todas las sociedades incluidas bajo el mismo identificador, y obliga a seleccionar la fila que se quiere generar el XML… ¿Alguien conoce alguna manera de saltarse esta pantalla y que se genere sólo el XML que cumple las condiciones indicadas al ejecutar el informe?

Muchas Gracias

Emiliano Carrasco.

Former Member
0 Kudos

Hola,

los grupos se generan en función de la granularidad que tenga definida el formato del medio de pago que tengas asociado a la Via de pago. Por ejemplo el formato CGI_XML_CT tiene pinchada 'Sociedad' y 'Banco propio'. Puedes hacer una copia del formato y modificar la granularidad.

saludos, Reyes

Former Member
0 Kudos

Buenos días Eduardo,

He avanzado mucho en la parametrización gracias a Note 1062489 - DMEE format for SEPA credit transfers y tambien la activación del IBAN que yo no lo tenia puesto (T77S0, ADMIN, IBAN)

Respecto al Support Package lo desconozco pero imagino que algo vendrá en los hilos específicos que SAP ha puesto a nuestra disposición sobre SEPA http://service.sap.com/SEPA y http://twitter.com/SAP_Gsupport

Saludos

Elia

Former Member
0 Kudos

Buenos días Eduardo,

Como te comentaba en la anterior respuesta, había activado el IBAN en la tabla T77S0 (ADMIN, IBAN).

Con ese paso es necesario rellenar el IBAN de todos los empleados en el infotipo 9 y 11. En caso de que se deje sin rellenar muestra el error "RP488 Indique un IBAN para vía de pago Transferencia"

Encontré una nota para generación masiva pero está disponible para otros paises y no está España Note 1397739 - SEPA: Mass generation of the IBAN

¿cómo has solventado tu esta parte?

Lo mismo ocurre con el código SWIFT de la tabla BNKA    

Gracias

Elia

juan_garaymoral
Explorer
0 Kudos

Buenos días, Elia.

¿Qué tal va todo? Nosotros hemos avanzado bastante y ya estamos haciendo pruebas con los bancos. ¿Habéis solucionado lo del NIF y las etiquetas vacías? Si necesitas ayuda, me dices.

Para calcular el IBAN nosotros hemos utilizado un archivo excel que nos han facilitado los de finanzas (creo que a ellos se lo dio algún banco). En éste, puedes meter los 20 dígitos de la cuenta y te genera el IBAN (aunque sólo de bancos españoles).

Para actualizar el infotipo 9, hemos creado un batch-input que haga un corte con el IBAN y la nueva vía de pago a partir de un excel.

En cuanto al SWIFT, nosotros vamos a actualizar el maestro de bancos desde la transacción BAUP, a partir de un fichero que tiene todas las sucursales de España. Una vez actualizado, en la parametrización de los bancos propios aparece el SWIFT. A nivel de los empleados, no lo vamos a actualizar porque en la transferencia lo coge directamente del maestro de bancos.

Si necesitas más información, no dudes en pedírmela.

Saludos,

Juan

former_member431450
Participant
0 Kudos

Hola, Elia.

Una alternativa para la carga de SWIFT en las Entidades bancarias (BNKA) es utilizar la transacción estándar BIC.

Por otra parte, la actualización masiva del IBAN en los infotipos 9, 11, 887 se puede implementar sin necesidad de un fichero externo, sino utilizando un MF para generar automáticamente el IBAN a partir de la CCC, que que puede ser CONVERT_BANK_ACCOUNT_2_IBAN. Es decir, se calcula el IBAN y, como sugiere Juan, se realiza un corte en los infotipos. Una alternativa al BI consiste en utilizar el MF  HR_INFOTYPE_OPERATION.

El caso del infotipo 57 es un tanto especial, porque el IBAN proviene de la Clave de receptor del pago (V_T521B), no se graba en el infotipo. Por lo demás, igualmente se realiza un corte a la fecha de arranque de SEPA.

La activación del IBAN en los infotipos, se puede realizar directamente con la parametrización de la tabla T77S0, pero también ejecutando el programa RPU_FILL_IBAN (ver nota 1266571).

Por cierto, aprovecho para lanzar una consulta : ¿es posible desde PMW (programa SAPFPAYM) ejecutar el medio de pago para formato SEPA_CT, para un empleado concreto?.

Gracias y Saludos.

Former Member
0 Kudos

Buenos días,

Para generar el fichero XML desde PMW para un empleado concreto, habría que preparar el intercambio de datos previamente a través de la transacción PC00_M04_CDTA y generar el pago para dicho empleado. Desde la transacción PC00_M99_FPAYM puedes seleccionar la ejecución creada y generar el fichero de pago.

Un saludo.

former_member431450
Participant
0 Kudos

Hola, José Miguel.

Lo que describes es el proceso general, tanto por el sistema clásico (FFOES) como con PMW : se identifica y se genera el medio de pago.

Pero la cuestión es : tengo una identificación con "n" empleados". ¿Puedo ejecutar PC00_M99_FPAYM para uno o varios de esos "n" empleados, de forma selectiva?.

Gracias y Saludos.

Former Member
0 Kudos

Buenos días Eduardo,

Por número de empleado yo creo que igual que ocurria con el RCFOES una vez identificada la transferencia para un grupo de empleados, no se puede generar para  uno de ellos. Si hubiese algo lo desconozco.

El report SAPFPAYM te da la opción de filtrar por datos de pago y nosotros para distinguir un colectivo que queriamos procesar de forma independiente, utilizamos el campo UZAWE para ejecutarlo. Si no es algo puntual y se tratan de casos identificables, podrias hacer algo así.

En el Enhancement HRPAYES_BANK_TRANSFER hemos programado que ese colectivo se distinga con un 01 en el campo UZAWE y cuando generamos el fichero SEPA jugamos según nos interese con ese campo.

Saludos

Elia

former_member431450
Participant
0 Kudos

Hola, Elia.

Gracias por tu aportación; es interesante lo que comentas con relación al HRPAYES_BANK_TRANSFER.

Finalmente, te puedo comentar que la selección por empleado (así como por otros parámetros), se puede realizar en el programa SAPFPAYM desde Delimitaciones opcionales. En concreto, el empleado se corresponde con el campo "Referencia al interloc.cial." (hay que completar ceros a la izquierda hasta los 8 dígitos).

Por cierto, si os habéis encontrado con algún problema al lanzar en fondo el SAPFPAYM, por ejemplo cuando hay ruptura del identificador con más de un banco, os agradecería si compartís vuestra experiencia.

Gracias y Saludos.

former_member431450
Participant
0 Kudos

Hola.

 

Hemos leído en las notas que, para la ejecución en fondo de PMW, es recomendable utilizar SAPFPAYM_SCHEDULE, en lugar de SAPFPAYM.


Lo que sucede es que, cuando en un número de identificación hay ruptura, por ejemplo por banco, el SAPFPAYM muestra una ventana donde el usuario selecciona el banco concreto que quiere pagar.


Sin embargo, en fondo (SAPFPAYM_SCHEDULE) no vemos la posibilidad de establecer una selección, paga para la totalidad de la identificación. ¿Hay alguna solución para este tema?.

Gracias y Saludos.

Former Member
0 Kudos

Buenas,

Ha aparecido la nota 1906119 en la cual se adjunta report para la modificación de los IT afectados para España.

Un saludo

S0005892775
Explorer
0 Kudos

Buenas,

También ha aparecido la nota 1943443 (SEPA: Utility program for payment method change in infotypes for Spain) la cuál tiene como prerrequisito la nota 1906119. Lo que no entiendo es que la nota 1943443 sea válida para el nivel de SP 48-69 (Release 604) y que la nota 1906119 sea válida para el nivel de SP 55-66 (Release 604).

Al aplicar la nota 1943443 nos da un error porque faltan includes que están en la nota prerrequisito 1906119, la cuál no podemos implementar porque no estamos en el nivel de sp que piden, pero sin embargo si estamos en el nivel de sp para aplicar la nota 1943443.

¿Os ocurre lo mismo?

Muchas gracias y un saludo, David.

JoRoGaPe2023
Explorer
0 Kudos

Hola buenas tardes,

Podeis decirme si el programa de actualizacion masiva de IBAN va a ser liberado para Espania?

muchas gracias.

lucia_iturbe
Active Participant
0 Kudos

Buenos días:

Siguiendo la recomendación dada por la "Asociación Española de Banca"
no está previsto entregar ninguna actualización automática para la
generación del IBAN y su registro en los infotipos.

Lamentablemente no existe ningún organismo oficial en España que
entregue ningún servicio para la realización de la conversión de cuenta
a IBAN. Lo único oficial sería la página
http://www.sepaesp.es/herramienta/conversion.htm que va cuenta a cuenta
pero además deja claro en el "Aviso legal" que no garantiza su correcto
funcionamiento.

Esta es la respuesta oficial de la "Asociación Española de Banca"
respecto a la generación del IBAN:
"Siendo consciente de la problemática que se plantea, creo que también
es importante asegurar que la información en origen es buena, porque no
podemos olvidar que en el sistema actual las operaciones se pueden
tramitar aún sin número de cuenta. De esta forma podría ocurrir que se
estén haciendo operaciones durante años y que tras una conversión masiva
existan incidencias en el procesamiento posterior. Por otra parte,
seguramente no es necesario explicaros la conveniencia de tener las
bases de datos actualizadas (hay muchas órdenes de pago con antigüedad
superior a 10 ó 20 años), y si hay un momento oportuno es este ya que
además de la necesidad de conversión de formatos, se junta la
reorganización de entidades/oficinas que se está llevando a cabo en el
sector financiero español. La mera transformación de los formatos CCC en
IBAN no es una garantía y por seguridad en los pagos nuestra
recomendación es siempre recabar la información de la contrapartida del
pago."

Adicionalmente en los cuadernos bancarios se indica:
"En ningún caso, el ordenante deberá efectuar cálculo para completar el
IBAN, debiendo recabarlo siempre del beneficiario de forma íntegra."

Un saludo, Lucía

former_member431450
Participant
0 Kudos

Gracias Juan / Elia.

Iré aportando al hilo mi experiencia, a medida que avance con la implementación.

Una consulta previa a la parametrización :

Para saber el nivel mínimo de Support Package del que se debe partir para montar las transferencias SEPA, para cada versión, ¿conocéis alguna página de referencia de SAP?. Si podéis facilitar algún link, lo agradecería.

Saludos.

Former Member
0 Kudos

Buenas tardes Eduardo,

¿Te han contestado por otro lado a tu consulta?.

Yo tengo la misma duda que tu, ya que desde Tecnologia de nuestra entidad, nos exigen adaptarnos desde el mes proximo a la normativa CSB34-14.

Actualmente el report que utilizábamos desde nómina para la generación de ficheros era RFFOES_T pero ya no nos va a servir.

Por favor, ¿alguien conoce el nuevo report o proceso de pago?

Gracias

Elia

former_member431450
Participant
0 Kudos

Hola, Elia.

Lo que he averiguado (si no me equivoco) es que en PMW hay un programa de pago estándar SAPFPAYM.

Es decir, la filosofía con PMW es disponer de un gestor centralizado de pagos, que sintetice los programas RFFOES* en uno sólo.

La identificación previa al pago se realizaría con el sistema clásico, es decir, transacción PC00_M04_CDTA.

Te agradezco si compartes cualquier info adicional que consigas, al respecto.

Saludos.

juan_garaymoral
Explorer
0 Kudos

Buenos días.

A ver si con lo que os cuente os puedo ayudar un poco.

Hace unos días conseguí generar un fichero con el formato SEPA. Como bien dices, la identificación previa al pago se hace con la transacción PC00_M04_CDTA y después se genera el fichero en formato XML con la transacción PC00_M99_FPAYM.

La parametrización previa es la siguiente:

1.- Verificar que exista el formato de pago SEPA_CT en la transacción OBPM1

2.- Crear vía de pago a nivel de país (transacción FBZP) en la que se indica que el medio de pago es PMW.

3.- Crear vía de pago en la sociedad (copiar de la T)

4.- Introducir el IBAN y el SWIFT/BIC del banco propio

5.- Realizar un corte en el infotipo 9 para introducir el IBAN y la nueva vía de pago.

6.- A nivel del usuario que ejecuta el pago, tuve que poner el parámetro "DCP = 4102" porque se producía un error en la transacción PC00_M99_FPAYM.

Ahora nos queda realizar pruebas con el banco y esperar que no haya muchos errores.

Espero que os sirva de ayuda.

Un saludo,

Juan

Former Member
0 Kudos

Buenos días Juan,

Muchas gracias por compartir esta estupenda guía!!!.

También habría que añadir a tus pasos el realizar un corte en los receptores de la vista V_T521B, poniendo la nueva vía de pago así como realizar corte en el infotipo 11 de los empleados.

En general es necesario revisar todos los infotipos que generen transferencias externas.

Continuando con las pruebas, he llevado a cabo todos esos pasos y efectivamente me genera un fichero XML pero te comento lo que me he encontrado.

- Las transferencias externas del infotipo 11, no consigo que las incluya en el fichero. Muestra el error "Se crearon demasiados medios de pago para este grupo de pagos"

- Al fichero XML le faltan datos en algunas etiquetas. ¿A ti te ocurre lo mismo?. Es por descartar si es por falta de parametrización.

A. CABECERA

<CstmrCdtTrfInitn> (NO ME LO GENERA SAP)

B. INFORMACION DEL PAGO

El CIF del ordenante no me lo rellena

<Id>XXXXXXXXXX</Id>

C. INFORMACION DE TRANSFERENCIA INDIVIDUAL

Me vienen vacias las etiquetas del NIF,BIC,IBAN del beneficiario y algunas etiquetas más como <BtchBookg>, <InstrPrty, <Cd>.

Un saludo

Elia

Former Member
0 Kudos

Hola,

con respecto a las etiquetas, se supone que InitgPty es obligatoria para la ISO 20022. Con respecto al sufijo, alguien sabe cómo se obtiene?

<InitgPty>
     <Nm></Nm>
     <Id>
      <OrgId>
        <Othr>
          <Id>nifsufijo</Id>
        </Othr>
      </OrgId>
     </Id>
</InitgPty>

Gracias

Former Member
0 Kudos

Hola,

quería comentar que desde las presentaciones del grupo de FI comentan por activa y por pasiva que el formato de transferencias para España será el CGI_XML_CT (hay notas que indican como cargarlo, etc... etc... )... en detrimento del que sale en la documentación que he visto hasta ahora de la parte de HR (que sería el SEPA_CT).

Estoy buscando confirmarción sobre este tema y no encuentro nada ¿alguno ha encontrado algo al respecto?...

Básicamente si efectivamente hay que centrarse en el CGI_XML_CT porque será el bueno o que para HR será diferente y habrá el SEPA_CT.

Gracias!

Francisco Vallejo

0 Kudos

Comparto la duda. Por lo que he entendido SEPA_CT es la estructura internacional, mientras que CGI_XML_CT es la propia de España. Si esto es así, creo que desde SAP HR España debería de afinarse la estructura CGI_XML_CT para su funcionamiento correcto y liberarla como solución final para España... Supongo que en la próxima reunión de Ausape Gemma nos lo aclarará...

Aprovecho para una duda añadida...Es sobre la vía de pago: SAP recomienda crear una nueva vía de pago, pero no da los motivos de no reutilizar la actual. Entiendo que es mucho más simple realizar el cambio de parametrización a fin que la vía de pago actual funcione para SEPA. No veo las desventajas de hacerlo así...

Cordialmente

former_member431450
Participant
0 Kudos

Hola.

Cuando les planteamos el asunto, desde SAP nos comentaron que no existía riesgo de utilizar SEPA_CT y SEPA_DD, porque no quedarían obsoletos.

Los formatos CGI_XML_xx son los que se localizan y se adaptan a los diferentes países (no todos).

Respecto a la reutilización de las vías de pago haciendo una transición de *FFOES* clásico a PMW para pagos SEPA, no hemos tenido ningún inconveniente.

Saludos.