6 Replies Latest reply: May 15, 2014 10:11 AM by Grant Perkins RSS

    Multi-line problem

    KEVIN KENNEDY

      I am trying to trap address blocks, some of which are address types that the postal trap does not work with.

      HEADERLINE1

      HEADERLINE2

      HEADERLINE3

       

      0000000099999996 0098 IN 99/99/99 X     999          .00000000          .00000000 99/99/99

       

      CUSTOMER NAME 1

      CUSTOMER NAME 1 ADDR

      USCITY ST  99999

       

      0000000099999997 0098 IN 99/99/99 X     999          .00000000          .00000000 99/99/99

       

      CUSTOMER NAME 2

      CUSTOMER NAME 2 ADDR

      FOREIGN CITY COUNTRY

       

      0000000099999998 0098 IN 99/99/99 X     999          .00000000          .00000000 99/99/99

       

      CUSTOMER NAME 3

      CUSTOMER NAME 4

      CUSTOMER NAME 3 ADDR1

      CUSTOMER NAME 3 ADDR2

      FOREIGN CITY COUNTRY

      /code

      The report has 1 line of detail for each record (represented by the long numeric string), followed by 1 blank line, followed by the address lines, followed by 1 blank line. I tried the multi-line with starting string on line 1, and ending on 'blank' and 'none of the above', but Monarch treats each line of the multi-line as a separate field. I am stumped. Any suggestions for the trap, or modifications to the report that will make the multi-line work? (Yes, I can manipulate the report.)

        • Multi-line problem
          elginreigner _

          Did you set your field to memo and then on the 'advance' tab, select how many lines you want? In this case, I would would set the number of lines for the memo field to the maximum number of multilines that is expected for the customer name and address.

          • Multi-line problem
            Grant Perkins

            I am trying to trap address blocks, some of which are address types that the postal trap does not work with.

            HEADERLINE1

            HEADERLINE2

            HEADERLINE3

             

            0000000099999996 0098 IN 99/99/99 X     999          .00000000          .00000000 99/99/99

             

            CUSTOMER NAME 1

            CUSTOMER NAME 1 ADDR

            USCITY ST  99999

             

            0000000099999997 0098 IN 99/99/99 X     999          .00000000          .00000000 99/99/99

             

            CUSTOMER NAME 2

            CUSTOMER NAME 2 ADDR

            FOREIGN CITY COUNTRY

             

            0000000099999998 0098 IN 99/99/99 X     999          .00000000          .00000000 99/99/99

             

            CUSTOMER NAME 3

            CUSTOMER NAME 4

            CUSTOMER NAME 3 ADDR1

            CUSTOMER NAME 3 ADDR2

            FOREIGN CITY COUNTRY

            /code

            The report has 1 line of detail for each record (represented by the long numeric string), followed by 1 blank line, followed by the address lines, followed by 1 blank line. I tried the multi-line with starting string on line 1, and ending on 'blank' and 'none of the above', but Monarch treats each line of the multi-line as a separate field. I am stumped. Any suggestions for the trap, or modifications to the report that will make the multi-line work? (Yes, I can manipulate the report.)[/QUOTE]

             

            I suspect confusion here but I'm not sure ...

             

            The 'Original' early Monarch Zip Code trap is not required (indeed is not desirable) if using the much more flexible Address Block functionality introduced later. It is offered for backwards model compatibility (mostly).

             

            Address blocks are in interesting subject and I heartily recommend reading the Help and the Training Guide in some detail to gain familiarity. Addresses can be very variable address database sources even more so - hence the opportunity to set an error code when the incoming data does not match your expectations or those of Monarch or the target system for any output! If you get better than an 80% success rate something is going very well somewhere. If it's worse than 30% I would abandon the data source as being worse than useless ....

             

            EXCEPT ....

             

            If you are dealing with address formats from multiple countries do remember that most, perhaps all countries likely to be thrown at you, addresses where some reasonable structure can be derived for addresses are catered for in Monarch BUT you need to set the options related to which rules about address formats you want to have Monarch look for as it processes the inputs you provide.

             

            If you have done all of that and still have problems then I think we may need to ask for some comprehensive samples to analyse with real data - too many variables to simply discuss in theory and the rules are very specific to certain expectations of recognisable data strings to work with proxy information.

             

             

            HTH.

             

             

            Grant Perkins

              • Multi-line problem
                KEVIN KENNEDY

                Thank you both. I modified the model to include the long detail line with the n&a block (I had the former as an append and the latter as detail), redefined the whole thing as detail, then used the address block to parse it. I hadn't learned previously about the address block. Errors are very low--few enough to deal with manually.

                  • Multi-line problem
                    Grant Perkins

                    Excellent result!

                     

                    The address block functionality is very powerful once you get to know it - but you need to have a feel for the quality of (and any potential problems with) the data source to really get the very best from it.

                     

                    If the objective is to export the resulting data elsewhere and given the low error rate  - are you able to use a user entry data field to make the fixes before export or does the work responsibility lie elsewhere after export?

                     

                    Grant

                      • Multi-line problem
                        KEVIN KENNEDY

                        I am working with a small dataset and can manipulate the lines (moving 2nd address line to 1st address line where 1st address line is blank, for example) in an interim step before I import the data into my database. About 5-10 minutes work.

                          • Multi-line problem
                            Grant Perkins

                            I am working with a small dataset and can manipulate the lines (moving 2nd address line to 1st address line where 1st address line is blank, for example) in an interim step before I import the data into my database. About 5-10 minutes work.[/QUOTE]

                             

                            Ah, that sort of data problem.

                             

                            Not too bad to deal with.

                             

                            On the other hand it may be worth considering an option to create the final output for the address lines using calculated fields such that if Line 1 is not blank use line one data but if it is use line 2 (or maybe line 3 ...?) and so on.  Likewise if Line 1 is blank and you have used line 2 then line 2 should, presumably, be whatever is in line 3  - or blank. And so on.

                             

                            Whether it is worth doing so depends, of course, on how often you have to assess and make the changes and whether the task is likely to remain the same or grow.

                             

                             

                            I tend to automate anyway if doing so looks like it won't take too long and the 'rules' for the automation look like they can be applied safely and consistently over time.

                             

                            Grant