Page break difficulties

[ltw]

I am trying to parse a report with a header that looks like this:
June 4, 2008


Rental Owner LLC UNIT 202 (ST202)
John Doe SEASIDE TOWNHOMES
123 Main Street
Anytown CA 12345


MONTH ENDING May 31, 2008



This is at the heading of each statement in a series of statements within the subject text file. The rest of each statement has many lines that look something like:

EXPENSES:
05/04/08 Complementary Maintenance WO 123456 0.00
05/01/08 Maintenance WO 123457 10.00
Etc.

This is the detail section and is treated as such with a detail template.

So the problem is with the heading section. I believe the best way to trap it is to use the date at the top. To do this, I need to use a floating trap on the year. This works if I make the header an append template. It does not work if I make the header a Page Header template because of the date that appears in the 'Month Ending...' line - it tries to make that the trapped line. This is further complicated by the fact that the owner address field can vary from 1-5 lines, thus requiring that I float the 'Month Ending...' line by starting the field using an 'After last defined field in template' selection.

So the difficulty with using an append template is that Monarch inserts page breaks automatically. If one of these page breaks lands in the middle of the append header, then it doesn't detect the 'Month Ending...' line.

Suggestions anyone?

[Bruce]

ITW
Welcome to the forum

Have you tried 2 appends? One for the name detail, then one for the Month ending section. Depending on where the page breaks land this could work well, or still fail.

Let us know either way.

Regards

[ltw]

I tried that. The problem is that the floating trap used to get the date on at the top also picks up the 'Month Ending...' part. The first couple of statements in the file are ok, but then it loses synch and the output is garbage. It will eventually resynchronize, but that doesn't last long.

Any other thoughts?
Thanks

[Grant Perkins]

You have not mentioned it so I guess it's not there but my favoured trap for a page header normally uses something connected with the Page Number.

Of course there are examples where the reports don't have a page number or at least not a trappable one.

If there really is nothing (spaces, dashed lines, anything really) that might help here - and a variable length page header is no help either - then you may be looking for some form of pre-process to transform that first line date into something more uniquely identifiable as a starting point.

The downside of that idea is, of course, finding a way to uniquely identify that line without using a floating trap.

For example - and this is just 'thinking aloud' - if you were to select all of every line (i.e. no trap) and could then pick any lines starting with a month name then a space then one or two numerics followed by a comma then a space and then a valid year number AND if you could be sure that such a combination would not occur anywhere else (unless that could be dealt with by further conditional processing) THEN you could transform the line by inserting something unique at the begining of the line, for example, and making an easy trap.

All other lines would be written as they are to a calculated field. The transofrmed line would be written to the same field and you now have a revised version of the report. Print it or export it and run another model against that version.

There may be some potential for dealing with the variable number of lines problem in the page header at the same time (or at least in a similar way).

Does that spark any ideas?


Grant

[OllyInMunich]

Hi ltw,

I mocked up a report file by copying your sample a few times, and inserting different dates and varying the address lengths.

I got a trap to work on the first line of the address, instead of the dates, so using a non-floating trap, with plain A alpha traps in columns 1 and 37 on line 4 of 10 (you might want to increase this if you have very long addresses), of an append template.

To capture the Month Ending you will need both "After last defined field" and "Blank field values" selected on the advanced tab, then a calculated field in the table to clean up the result.

HTH

Olly

[ltw]

Grant and Olly,
Thanks for your thoughts on this.

First, pre-processing the file as Grant describes is an option that I hadn't thought of, but may work well. I may be able to clean up a number of things by doing this. I will look into it.

With regards to the solution proposed by Olly, I will give it a try and see if there is anything else in a full length file that might interfere. The snippet that I provided is real - I just changed the names, etc. - but it is also only a single case in a variety of possibilities.

As a side note, I recently posted a note in the Monarch future improvements thread suggesting adding the ability for use of Regular Expressions for trapping and extracting. I have used Regular Expressions before with good results, and believe that some of these kinds of difficulties could be more easily delt with using that technique. I don't know if I am unique in my view on this, but it was a thought.

Thanks again. Let me know if you have further thoughts.
...ltw