How many of those lines of data do we actually need as test cases? Is there something special we should be noticing about the lines that we require more than two sample lines?

Maybe it's hidden by the sample data, but I don't see the code you have tried nor a description of how that code fails. In fact I can't even spot the example expected output. See I know what I mean. Why don't you?.

If you shows us your perl code and attempts at parsing, with the results expected and achieved, and articulate specific issues you encounter, we will be happy to assist you get closer to desired results.

Here is a little code segment to get you started:

while(<DATA>){
    my $date;
    $date = $1 if s/(\d+\.\d+\.\d+)\s*//;
    my $ccy;
    $ccy  = $1 if s/([a-z]+)\s*//i;
    print "Date=$date, Currency=$ccy, Rest=$_\n" if $date && $ccy;
}
[download]

assuming you have your data in the DATA segment. Dealing with processing the remaing fields is left as an exercise. You might want to consider splitting on semicola...

30.6.89 CH 2454/89-7<cr><o:p></o:p>
25.1.94ch209/94-6;8.12.94ch3714/94-1<o:p></o:p>
25.1.94 ch 209/94-6 ; 8.12.94 ch 3714/94-1<o:p></o:p>
4.10.99 PCT PCT/IB99/01618 ; 11.10.99 PCT PCT/IB99/01660<o:p></o:p>
20.5.97 USA (prov.) 60/047; 168<o:p></o:p>
20.5.97 ch(pct) pct ib97/00575<o:p></o:p>
us 31.10.03 60/516; 548 ; PCT 31.10.03 PCT/IB03/04867
pct 19.03.03 pct/ib03/01079<o:p></o:p>
[download]

Are these indeed each different formats or are it typos perhaps? Some lines seem to have two records on one line? Or did you forget to add a newline between the records?

Is the whitespace a simple space (one or more) or are it perhaps tabs?

It would help us all if you could show us the desired result for each of the above lines.

Well, the short-answer would be, “very carefully!”   Because, even in this snippet of data, I see inconsistencies.   Some lines appear to begin with pct while others do not.   The last line of your example is very different.

It will be crucial that you design your program to be suspicious.   It should aggressively test every assumption that it makes, so that it will die (on its own ... descriptively ...) when it encounters any line of data that does not perfectly meet those assumptions.   This is because, in the real world, programs such as this one are the only way for anyone to know whether there are any inconsistencies in the input-data.   (Yes, you are effectively “debugging” that upstream program, and yes, on a very-regular basis you will find bugs in it.)   You need to design these programs so that, if they run to completion, then you have in this a very strong indicator that all of the data ... and there could of course be many megabytes of it per-run ...is okay.   And that, therefore, the results produced are probably reliable.

Put such tests into the program from the very start, until you are absolutely sure all is well.   Then, and only then ... leave them in!

It will be crucial that you design your program ...

You offer much wise advice. Unfortunately, I think droberts2014 isn't interested in designing anything. I think droberts2014 thought it would be worth spending thirty seconds of time to plunk a great wadge of (probably unusable) 'data' down in the middle of the site, slap "if there are multiple entries then just make more colums Thanks for the ehelp!!" on it, and sit back and see what happened. (Anyone notice any cross-posting? Wouldn't be surprised...)