I've come up with a solution that worked in v5 Standard.
I created a one line detail template, trapping the IT in column 1. I set the End Field On: Minimum action only. I defined the field as "IT Field".
I then created a two line append template, again with IT in position 1 of the trap line. Once again I set the End Field On: Minimum action only option. I defined the field as "Pre PID Field".
What you wind up with in the table is a PID Field for partnumber3 which includes partnumber4 and the PID description for partnumber4.
Knowing that you only want the PID description when it starts the field, not part-way into it, we can take advantage of this.
Build a calculated field named "PID Field" with this formula:
[font="courier"]If(Instr("PID",[Pre PID Field])>1,"",[Pre PID Field]) /font[/quote]This will return a blank field if the PID tag isn't in the beginning of the field; meaning that it doesn't really belong to this partnumber, so you want to ignore it.
If however it does start the field properly, then great, use it as extracted.
While there may be more elegant way (I've certainly had better template success with v8 and v9), this worked fairly quickly. Sorry, I don't have more time at the moment to find that "perfect" solution.
Further to Kruncher's solution your requirement is a little similar in concept to this recent problem.
I think the concept of overlapping an append on to a detail trap, using the preceding string concept to determine whether the variably present line exists, should work for you. As far as I remember it should be possible in V6.
The append detail should then appear when it appears or give you an empty field if it does not exist. But the append should always be reset by the next record and therefore not carry over to records to which it should not apply.
Worth a try at least.
If this is easier with a newer version however, I will upgrade just so it will be easier to teach others. /b[/quote]Glad you found a solution. There are many ways, usually, to derive what you need to derive, often all equally as good as the others.
I would always recommend the upgrades since Monarch has added functionality with every new version.
That said I don't think there is anything much to add to the basic concept of the solutions suggested. You can have more appends and footers these days but you don't seem to need them much!
However, if you are teaching others, from which I infer you will be mentoring a few more Monarch users, then V9 may offer something more useful than simplified teaching.
The V9 concept of Linked Objects might (it depends on your interoperational requirements) prove interesting for sharing operational functionality and being better able to manage models for consistency and the timeliness of any changes that may be required.
A further extension of that idea which may be valuable could be the Used Defined Functions functionality which would allow you to create a 'central' repository of 'functions' that all could share. The implication is that other users may not need to know the 'mechanics' of Monarch, rather just what operational tool they need for their model's analysis and where to get it.
I would predict faster and more consistent model development using V9. How much faster and how much benefit is difficult to suggest without knowing your needs and likely model development volumes.
Certainly worth spending a little time investigating though.