That is a "cartesian product" thing, mainly the context for the for-each starts from the root /. It is not a matter of want it or not. It is a matter of rightly or wrongly doing the task. But I think since the working within the loop seems at least superficially not coupling between the two elements selected, I don't think you really mean to have a cartesian product over them.
The other end of the spectrum would be this, if you want to select either of them encountered along the way...
It may fit what you need or it may not : no way to know.
Within the xsl:for-each, if you perform different work according to whether the context being imp1:EntryDetailRec or imp1:AddendaRec, you can use a conditional with test like this (to simplify the matter)
In any case, I see the rest of the template contains quite a few obvious errors such as this, as a typical example, cannot be right:
<xsl:if test='../imp1:AddendaRec/imp1:ReturnReasonCode = "01" or "06"'>
Besides the ../imp1:AddendaRec construction is problematic --- it will go back to the first encounter of imp1:AddendaRec to make the test (most probably not what you want???), the "or" keywork is not used like this. A possible rewrite that might inspire you to do the right thing is this.
Another kind of probable errors appearing more than once is
In any case, that is the different aspects you might work alone with correcting the template in question.
Joined: Mar 18, 2014
I have tested with sample payload and tried to use /imp1:GENVNDRReturnedItem/imp1:EntryDetailRec|/imp1:GENVNDRReturnedItem/imp1:AddendaRec . In payload first set am getting with both EntryDeatilRec and AddendaRec. Second set is EntryDeatilRec is null values and AddendaRec values are same as first set values.
Joined: Jan 18, 2011
With that cryptic report, I take it meaning it is not helpful. I can bear with it, good luck.
subject: for-each executions required seperately, but not in nested for-each for a complex xslt mapping