Shaun,
Based on the variant tree you show you would:
ITERATE through the ORC Group using a group counter (let’s say %g1).
The NTE for that group will need its ITERATE to have a segment counter (let’s say %s1) BUT you need to also place the ORC Group counter (%g1) in the appropraite location in the addrress path of the Basis for the ORC/NTE ITERATE as wll as in the appropriate address path locations within any Actions you use to reference the ORC/NTE.
The same would hold true for the other goups and they would each get thei own Group counters – say %g2 and %g3. You could reuse the %g1 Counter but the location will be different in the address paths.
I suspect the reason this structure is defined is because in the standard the ORC and OBR are at the smae level and the NTE after the OBR is at that levle as well then the OBX group is subordinate to the ORC group BUT there is no NTE with the ORC and I believe the HL/7 standard (and thus Cloverleaf) does not allow the same segment to appear multiple times within the same group.
Are you sure the vendor will be sending an NTE after the ORC and the OBR? If not then you could simplify things by simply using the standard and move the OBR NTE to the ORC NTE.
One more thing the way this variant is constructed this is the way I would expect to see the messages:
ORC
NTE
ORC
NTE
ORC
NTE
… for as many ORC groups that exist
OBR
NTE
OBR
NTE
… for as many OBR groups that exist
OBX
NTE
OBX
NTE
… for as many OBX groups that exist
Somehow I don’t think that is what they will send. It might be something like this:
ORC
NTE
OBR
NTE
OBX
NTE
OBX
NTE
ORC
NTE
OBR
NTE
OBX
NTE
OBX
NTE
and so on…
If the above is what you see then your variant will not work but you can define one that will work – ORC Group with NTE and OBR group with NTE subordinate to the ORC group then OBX with NTE group subordinate to the OBR group.
Well anyway that is my take.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
.
.