Interpreter Unrecognised Type for UNH

[mtdavidson]

I've noticed that when using the Interpreter in the JSON result I'm seeing

"UnrecognisedType":["UNH","142",["DESADV","0","96A","UN"]]

for the message header.

It seems that this should perhaps be passed with the services segments instead of as regular segments but this becomes tricky if you're dealing with a multi-message file.

It seems that the specification for the UNH segment used to be in some files in particular D95B segments ( https://github.com/sabas/edifact-data/commit/8b0623d8f5e6b2acaf26ca66a874911926805bae#diff-c62143c05b98d29cea5c222856db8f83 ) which has been removed but not on the version that is currently the submodule for this project.

What do people think? The simple fix would be to add UNT, UNH and UCM into the segments.xml for each standard but that seems hacky.

[sabas]

I removed them because I discovered they're already defined in this folder https://github.com/sabas/edifact-data/tree/master/Service_V3 where v3 is the syntax version

They need to be loaded in $xmlSvc https://github.com/sabas/edifact/blob/master/src/EDI/Interpreter.php#L35

[mtdavidson]

So we could do that in the splitMessages switch statement https://github.com/sabas/edifact/blob/master/src/EDI/Interpreter.php#L88

Maybe instead of

$tmpmsg = [$segment];

do

$service['UNH'][] = $segment;
$tmpmsg = [];

that way to cope with multiple messages in the same file but still get the UNH for each one?

If not alternative would be to put an additional piece of logic in the loopMessages function to make use of that $xmlSvc for particular lines.

[sabas]

@mtdavidson is this issue still valid?

[mtdavidson]

Yes I believe so. We didn't make use of UNH in our project in the end so I just ignored it.

[sabas]

Should be fixed by 6e3aeb74088f3eb6f4bf5b51e2b430a5094fc99a