Reglas de validación para estándares específicos
En este apartado se describen las reglas de validación que realiza MapForce para diferentes estándares EDI. Para más detalles siga leyendo.
Reglas de validación EDIFACT/ONU
MapForce realiza diferentes comprobaciones de validación en función de si se trata de un mensaje EDIFACT/UNO estándar o interactivo.
Mensajes EDIFACT estándar
Cuando se validan documentos EDIFACT/ONU estándar, MapForce comprueba:
•si existen los segmentos UNB e UNZ.
•si UNB/S004 contiene una especificación válida de fecha y hora.
•si UNB/0020 y UNZ/0020 contienen el mismo valor.
•si UNZ/0036 contiene el número correcto, que se define como número de grupos funcionales o como número de mensajes. Si existen grupos funcionales, debe ser el número de grupos funcionales. De lo contrario, debe ser el número de mensajes que contiene el intercambio.
Grupos funcionales
En cada grupo funcional se comprueba:
•si el grupo contiene los pares UNG y UNE correspondientes.
•si UNG/S004 contiene una especificación válida de fecha y hora.
•si UNE/0060 contiene el número correcto de mensajes.
Mensajes
En cada mensaje se comprueba:
•si el grupo contiene uno o varios pares UNH y UNT correspondientes.
•si UNH/S009/0052 contiene el mismo valor que UNG/S008/0052 del grupo funcional contenedor.
•si UNH/0062 y UNT/0062 contienen el mismo valor.
•si UNH/S009/0065 contiene el especificador de tipo de mensaje correcto.
•si UNT/0074 contiene el número correcto de segmentos.
Mensajes EDIFACT interactivos
Las siguientes reglas de validación se aplican a componentes de MapForce que contienen mensajes EDIFACT interactivos:
•Si UIB está presente, entonces todos los segmentos UIH/S302 subsecuentes deben coincidir con UIB/S302
•UIH/S306/F0065 debe contener un tipo de mensaje (validado por el analizador).
•UIH/S306/F0052 debe contener el número de versión de mensaje que está definido en los archivos de configuración seleccionados.
•UIH/S306/F0054 debe contener el número de publicación de mensaje que está definido en los archivos de configuración seleccionados.
•UIT/F0340 debe coincidir con el encabezado/finalizador de mensaje UIH/F0340 correspondiente (campo opcional).
•UIT/F0074 debe contener el recuento de segmentos (campo opcional).
•UIZ/S302 debe coincidir con UIB/S302 o no estar presente (compuesto opcional).
•UIZ/F0036 debe contener el recuento de mensajes o no estar presente (campo opcional).
Reglas de validación ASC X12
Cuando se validan documentos ASC X12, MapForce comprueba:
•si existen los segmentos ISA e IEA.
•si ISA/I01 contiene un calificador de información de autorización legal.
•si ISA/I03 contiene un calificador de información de seguridad legal.
•si los segmentos ISA/I05 contienen calificadores de Id. de intercambio legales.
•si ISA/I08 contiene un valor de fecha con un formato correcto.
•si ISA/I09 contiene un valor de hora con un formato correcto.
•si ISA/I13 contiene un valor booleano legal.
•si ISA/I14 contiene un indicador de uso de intercambio legal.
•si ISA/I12 e IEA/I12 contienen el mismo valor.
•si IEA/I16 contiene el número correcto de grupos funcionales del intercambio.
Grupos funcionales
En cada grupo funcional se comprueba:
•si contiene el par GS y GE correspondiente.
•si GS/373 contiene un formato de fecha con un formato correcto.
•si GS/337 contiene un formato de hora con un formato correcto.
•si GS/28 y GE/28 contienen el mismo valor.
•si GE/97 contiene el número correcto de mensajes del grupo funcional.
Mensajes
En cada mensaje se comprueba:
•si contiene el par ST y SE correspondiente.
•si ST/143 contiene el identificador de mensaje correcto.
•si ST/329 y SE/329 contienen el mismo valor.
•si SE/96 contiene el número correcto de segmentos del mensaje.
Reglas de validación HIPAA X12
Los componentes HIPAA son parecidos a los componentes ANSI X12 ordinarios. La validación se lleva a cabo igual que con los componentes X12 (véase el subapartado anterior). A continuación explicamos en qué se diferencian de los mensajes X12:
•MapForce automáticamente mantiene la jerarquía de los segmentos HL.
•MapForce admite las llamadas estructuras flotantes (en 837 mensajes).
•MapForce aplica finalización automática y valida más campos.
Reglas de validación NCPDP SCRIPT
Con respecto a mensajes NCPDP SCRIPT, MapForce realiza estas comprobaciones de validación:
•UIB/S001/F0001 debe ser UNOA.
•UIB/S001/F0002 debe ser 0.
•UIH/S306/F0329 debe contener el tipo de mensaje SCRIPT.
•UIH/S306/F0316 debe contener el número de versión de mensaje que está definido en los archivos de configuración seleccionados.
•UIH/S306/F0318 debe contener el número de publicación de mensaje que está definido en los archivos de configuración seleccionados.
•UIH/S306/F0326 debe contener función de mensaje (o el tipo de mensaje si seguimos la terminología de MapForce).
•UIT/F0062 debe coincidir con el segmento UIH/F0062 correspondiente.
•UIT/F0074 debe contener recuento de mensajes o no estar presente.
•UIZ/F0036 debe contener recuento de mensajes o no estar presente.
TRADACOMS
Para los archivos TRADACOMS, MapForce realiza las siguientes comprobaciones de validación durante el análisis sintáctico o la generación del archivo:
1.Los segmentos STX (comienzo de la transmisión) y END (fin de la transmisión) deben existir.
2.Si STDS-1 tiene como valor 'ANAA', entonces debe existir un mensaje de reconciliación (RSGRSG) antes de que termine la transición (END). De lo contrario, no es necesario que exista un mensaje de reconciliación (RSGRSG).
3.Si STDS-1 tiene como valor 'ANAA', entonces:
a.El valor de RSGA en el mensaje de reconciliación debe ser igual al valor de SNRF en el segmento STX.
b.El valor de RSGB en el mensaje de reconciliación debe ser igual al valor de UNTO-1 en el segmento SXT.
4.TRDT-1 debe contener la fecha (YYMMDD) y TRDT-2 debe contener la hora (HHMMSS) de la transmisión (fecha y hora actuales).
5.Si el encabezado del lote (BAT) está presente también debe estarlo el pie del lote (EOB) y el número de mensajes del lote debe estar disponible en el elemento de datos NOLI (número de mensajes en el lote).
6.El elemento de datos MSRF (Message Reference) del encabezado del mensaje (MHD) debe contener el recuento consecutivo de los mensajes de la transmisión, empezando por el número 1.
7.El elemento de datos NOSG (número de mensajes en el segmento) del pie del encabezado (MTR) debe contener el número de segmentos, incluidos MHD y MTR.
8.Si existe, el mensaje de reconciliación (RSGRSG) debe consistir en cualquiera de los segmentos (RSG) menos el encabezado y el pie.
9.El elemento de datos NMST (número de mensajes en la transmisión) del segmento END debe contener el número de mensajes en el intercambio (recuento te segmentos MHD).
10.Por lo general, al leer una estructura TRADACOMS, MapForce espera que el entorno del intercambio sea de tipo "equipo a equipo" (o, en terminología TRADACOMS, "terminal inteligente a terminal inteligente"). Por tanto, un segmento como MHD = 12 + ORDHDR :3 generaría un error de validación, ya que contiene espacios extra no permitidos.
11.Los datos de las cadenas deben estar en mayúsculas, así que al generar resultados TRADACOMS, MapForce pasa los datos a mayúsculas.
Estas reglas de validación también hacen que MapForce rellene automáticamente los campos faltantes durante la generación del archivo.