Validaciones
Validation API
SEPADD PASO2 CSM Service proporciona un Validation API para habilitar los flujos de implementación del cliente o los clientes de SDK para enviar los lotes únicamente con fines de validación. La solicitud al API no conduce a que los lotes sean enviados para la Recolección y Liquidación.
La respuesta del Direct Debit Validation API is Direct Debit Validation API que puede comprender un nivel de mensaje OrgnlGrpInfAndSts bloque, nivel de transacción TxInfAndSts block(s) y (si se solicita) un schemeFormatMessage block.
Valide las reglas del esquema de domiciliación bancaria
Las Reglas del Esquema de Domiciliación Bancaria API La regla lleva a cabo las validaciones en los lotes enviados y las transacciones incluidas y proporciona una respuesta de validación. A continuación, se realizan las siguientes validaciones:
-
Validación a Nivel de Mensaje (Bulk validaciones de nivel)
-
Validación de los totales del encabezado del grupo, como el conteo de transacciones y los montos de liquidación interbancaria.
-
Reglas del Esquema Validaciones contra los campos del Encabezado
-
-
Mapeo del mensaje en formato canónico IPF al mensaje en formato de esquema.
-
Validaciones de Transacciones Individuales y Validaciones de Reglas del Esquema
-
Verificación del esquema de las validaciones finales
Las Validaciones API puede devolver el mensaje en formato Scheme en la respuesta si se solicita en la solicitud si el 'returnSchemeMessage' la bandera se establece en Verdadero. Las transacciones que no superen las validaciones serán eliminadas del mensaje de formato, por lo que el mensaje de formato de salida siempre será aceptable por el esquema. Al eliminar las transacciones fallidas, el CSM el servicio ajustará los totales del encabezado del grupo (conteo de transacciones y montos), para que coincidan con las transacciones que han pasado las validaciones. El SEPA DD CSM Service no altera el contenido de las transacciones individuales de ninguna manera, por lo que la transparencia de las transacciones se mantiene siempre.
Tenga en cuenta que las validaciones a continuación no se realizan cuando se envían los lotes a la Validation API.
-
Verificación de duplicados en los lotes enviados
-
Verificación de duplicados a nivel de transacción
-
Validaciones contra las fechas de liquidación presentadas en los lotes.
No se realizan verificaciones de duplicados en Validation API llamadas, para asegurar que el mismo volumen pueda ser enviado múltiples veces para validación sin ser rechazado como duplicado en intentos posteriores o cuando finalmente se envíe para compensación y liquidación.
Las validaciones de la fecha de liquidación interbancaria no se realizan en Validation API llamadas, ya que estas fechas pueden ser actualizadas al enviar a la Direct Debit API para la liquidación.
Consulte la especificación de validación aquí.Direct Debit Validation API
Procesamiento de Solicitudes API
SEPADD PASO2 CSM Service admite las siguientes validaciones en los envíos masivos provenientes de los flujos de implementación del Cliente. Es importante señalar que algunas validaciones pueden no ser aplicables según la fuente de la solicitud. (Consulte las características individuales para comprender las validaciones aplicables).
Las reglas del esquema se identifican y hacen referencia a la documentación del esquema (Especificaciones de Interfaz SDD de STEP2, Descripción Funcional de SDD de STEP2).
Todos los tipos de mensajes tendrán una verificación de esquema realizada utilizando la versión actual del esquema xsd. Esta acción realizará todas las verificaciones técnicas necesarias en el mensaje, tales como tipos de datos, cardinalidad y tamaño de los elementos de datos. Además de estas verificaciones técnicas, el SEPA CSM realiza verificaciones a nivel empresarial, para asegurar que los datos ingresados en cada campo cumplan con las reglas adicionales a las verificaciones técnicas básicas (por ejemplo, la fecha de liquidación no debe ser más de 14 días hábiles en el futuro, cualquier código ISO debe ser válido para el uso particular o los totales calculados deben ser iguales a los conteos a los que se relacionan).
Mensajes entrantes
Los mensajes que lleguen del esquema recibirán una verificación técnica contra su XSD. Esto se aplica a todos los tipos de mensajes soportados que lleguen a Debulker from SEPA PASO2 en los siguientes archivos:
-
DVF
-
RSF
Las validaciones a nivel empresarial están documentadas en las tablas de mensajes entrantes a continuación.
Los mensajes entrantes del esquema que no superen la validación aún se enviarán al cliente; sin embargo, se agregarán a un dedicado Kafka tema que debe ser dirigido a una implementación de procesamiento de excepciones. El SEPA El paquete del esquema DD no tiene un mecanismo para el rechazo automatizado de un mensaje entrante.
Reglas de Validación
Recolección y Liquidación (Pacs. 003)
Reglas a Nivel de Mensaje
| Regla | Procesamiento de Solicitudes API | Validation API | Descripción |
|---|---|---|---|
Validación del Modelo Canónico |
|
|
Validación contra el modelo canónico antes de mapping(FF01) |
Verificación de duplicados de mensajes |
|
|
Los siguientes campos se mencionan como parte de la verificación de duplicados:
(B14) |
Fecha de Liquidación Interbancaria |
|
|
|
Validación de esquema XSD |
|
|
Validación del esquema contra el esquema XSD después de mapping(FF01) |
Validación de Totales de Encabezado de Grupo |
|
|
|
Sistema de Compensación de Encabezado de Grupo y Validación de Agente Instruccional |
|
|
|
Reglas a Nivel de Transacciones
| Regla | Procesamiento de Solicitudes API | Validation API | Descripción |
|---|---|---|---|
Verificación de Duplicados de Transacciones |
|
|
Los siguientes campos se verifican en busca de duplicados:
(AM05) |
Verificaciones del Nivel de Servicio |
|
|
DrctDbtTxInf. PmtTpInf. SvcLvl. Cd debe contener 'SEPA' (XT33) |
Verificaciones de Instrumentos Locales |
|
|
DrctDbtTxInf. PmtTpInf. LclInstrm. Cd debe contener 'CORE' (XT33) |
Agente de Deudor/Creedor SEPA COM Pacifique Verificación |
|
|
|
Instrucción de Verificación de Agente |
|
|
DrctDbtTxInf. InstgAgt. FinInstnId. BICFI no debe ser poblado (XT13) |
Verificación de la Fecha de Recolección Solicitada |
|
|
|
Verificación del Código de País de la Dirección Postal |
|
|
|
Verificación de Códigos de País de la EEA |
|
|
La dirección postal del deudor es obligatoria si el agente deudor y/o el agente acreedor no se encuentran en el EEE. Nota-esta validación está desactivada por defecto-ver página de configuraciones
|
Verificación Estructural de la Dirección Postal |
|
|
Las direcciones se clasifican de acuerdo con los campos de dirección completados según Apéndice A: Validaciones Estructurales de Direcciones Postales
Nota-estas validaciones están desactivadas por defecto-ver página de configuraciones. |
Verificación del Id y Nombre del Esquema del Acreedor |
|
|
|
Enmiendas al Mandato |
|
|
|
Verificación de la Longitud del Nombre de la Parte |
|
|
|
Verificación de la Longitud de la Información de Remesas Estructuradas |
|
|
DrctDbtTxInf. RmtInf. Strd no debe exceder 140 caracteres (donde el número de caracteres se cuenta entre las etiquetas estructuradas, no inclusivas) (XT33) |
Solo una ocurrencia de DrctDbtTxInf. RmtInf está permitido |
|
|
DrctDbtTxInf. RmtInf no debe contener más de 1 ocurrencia de información de remesas estructurada y no debe contener más de 1 ocurrencia de información de remesas no estructurada. El modelo de datos STEP2 SDD permite hasta 10 ocurrencias, pero una regla de uso adicional especifica que solo se permite 1 ocurrencia de cada tipo (XT13) |
Cancelación (Camt. 056)
Reglas a Nivel de Mensaje
| Regla | Procesamiento de Solicitudes API | Validation API | Descripción |
|---|---|---|---|
Validación del Modelo Canónico |
|
|
Validación contra el modelo canónico antes de mapping(FF01) |
Validación de esquema XSD |
|
|
Validación del esquema contra el esquema XSD después de mapping(FF01) |
Verificación de duplicados de mensajes |
|
|
Los siguientes campos se mencionan como parte de la verificación de duplicados:
(B14) |
Validación del Agente Asignador |
|
|
Assgnmt. Assgnr. Agt. FinInstnId. BICFIla longitud es mayor que 8 (B12) |
Validación del Número Total de Transacciones |
|
|
CtrlData. NbOfTxsno es igual al número de transacciones en el lote (B03) |
Reglas a Nivel de Transacción
| Regla | Procesamiento de Solicitudes API | Validation API | Descripción |
|---|---|---|---|
Verificación de Duplicados de Transacciones |
|
|
Los siguientes campos se verifican en busca de duplicados:
(AM05) |
Validación de ID del Nombre del Mensaje Original |
|
|
Si Undrlyg. TxInf. OrgnlGrpInf. OrgnlMsgNmId no comienza con pacs.003(XT33) |
Validación UETR Original |
|
|
Si Undrlyg. TxInf. OrgnlUETR está presente (XT81) |
Validación del Agente Asignador |
|
|
Si Undrlyg. TxInf. Assgnr. FinInstnId. BICFI está presente (XT13) |
Fecha de Liquidación Interbancaria Original |
|
|
|
Reversión (Pacs. 007)
Reglas a Nivel de Mensaje
| Regla | Procesamiento de Solicitudes API | Validation API | Descripción |
|---|---|---|---|
Validación del Modelo Canónico |
|
|
Validación contra el modelo canónico antes de mapping(FF01) |
Fecha de Liquidación Interbancaria |
|
|
GrpHdr. IntrBkSttlmDtno es la Fecha de Liquidación Interbancaria Actual (B15) |
Validación de esquema XSD |
|
|
Validación del esquema contra el esquema XSD después de mapping(FF01) |
Verificación de duplicados de mensajes |
|
|
Los siguientes campos se mencionan como parte de la verificación de duplicados:
(B14) |
Validación de Totales de Encabezado de Grupo |
|
|
|
Sistema de Compensación de Encabezado de Grupo y Validación de Agente Instruccional |
|
|
|
Validación de ID del Nombre del Mensaje Original |
|
|
Si OrgnlGrpInf.orgnlMsgNmId no comienza con pacs.003(XT33) |
Reglas a Nivel de Transacción
| Regla | Procesamiento de Solicitudes API | Validation API | Descripción |
|---|---|---|---|
Verificación de Duplicados de Transacciones |
|
|
Los siguientes campos se verifican en busca de duplicados:
(AM05) |
Verificación del Código de Motivo de Reversión |
|
|
Si TxInf. RvslRsnInf. Rsn. Cd no es uno de AM05, MS02 o MS03 (XT33) |
Fecha de Liquidación Interbancaria Original |
|
|
|
Verificación del Agente Instruccional de Transacciones |
|
|
Si TxInf. InstgAgt.finInstnId.bicfi está presente (XT13) |
Transacción Invertida Monto Instruido Verificación |
|
|
|
Transacción Revertida Verificación del Monto de Liquidación Interbancaria |
|
|
Si TxInf. RvsdIntrBkSttlmAmt no es igual a TxInf. OrgnlIntrBkSttlmAmt plus TxInf. ChrgsInf. Amt (XT78) |
Entrante pacs.002
Se realizan las siguientes validaciones en una entrada pacs.002 del esquema.
Apéndice A: Validaciones Estructurales de Direcciones Postales
| Línea de dirección poblada | Nombre del pueblo Poblado | País Poblado | Cualquier otro campo de dirección completado | Clasificación |
|---|---|---|---|---|
No |
Sí |
Sí |
– |
Estructurado |
Sí |
No |
Sí |
No |
No estructurado |
Sí |
No |
No |
No |
No estructurado |
Sí |
Sí |
Sí |
– |
Híbrido |
Si está configurado, las transacciones que no pueden clasificarse como uno de los tipos de dirección mencionados anteriormente resultarán en un fallo de validación.