Complex Conversion

[Tom Pellitieri]

While writing a new contact tracking screen, I wanted to make it easier to enter phone numbers, but have them in a consistent format, specifically ###-###-####.  I have users who will use any of these formats, which I want to avoid.

###/###-####
###.###.####
(###) ###-####

I need to store the numbers in proper format to simplify raw data exports.

I wound up writing an Assignment process (/PD.A) called MY.ICONV.PHONE.  It reassigns @VALUE to

OCONV(ICONV(@VALUE,"MCN"),"ML(#3-#3-#4)")

In the Field Definition F6, I set the Input Conversion to

(P("MY.ICONV.PHONE"))

In my /SD, I had to add the standard @REFRESH=2 in the Process After slot of the corresponding fields to update the displayed value.

[precisonline]

Intriguing!  I usually use a validation to do that but an input conversion is an intriguing thought!

[Tom Pellitieri]

I still use the validation, but the conversion cleans up the input before validation.  The ICONV extracts just numbers from the input, then the OCONV masks it into the standard format.

This saves typing, since my users can just type the 10 digits and not worry about punctuation.

[Craig Vining]

Funny because we had this issue too!  During a training session with Kevin, he taught me the way he does these validations.  His solution is a simple paragraph:

@VALUE = @VALUE"MCN"
IF LEN(@VALUE)=10 THEN
  @VALUE=@VALUE"ML###-###-####"
  @REFRESH = 7
END ELSE
  ERROR 'This is not a valid phone number'
  EXIT 1
END

The benefit I notice in using the paragraph is the validation of the length. I could easily see one of our users enter in 1800/123-4567 which would strip the last digit '7' in your solution.  Which brings me to the question, have you run into the length issue?  Or have you solved this another way?