Digits element stripping leading zeroes

[sbalmos8089]

In a call studio app deployed to a PCCE 11 CVP server, I am collecting 8 digits in a Digits element, for a date stamp of the format MMDDYYYY. In testing, the Digits value is stripping the leading zero, causing a later usage in a Say-It-Smart Date element to fail. I have a custom log entry in the Digits element, created after, in order to re-log the element value. In the log, the element value string includes the leading zero. However, the custom log entry (and further uses of that element value) has the leading zero stripped. Ideas?

10.196.3.113.1476808046557.2.TestIVR,10/18/2016 11:27:37.948,F_Collect_DOB_2,enter,

10.196.3.113.1476808046557.2.TestIVR,10/18/2016 11:27:41.448,F_Collect_DOB_2,custom,dob,4111941

10.196.3.113.1476808046557.2.TestIVR,10/18/2016 11:27:41.448,F_Collect_DOB_2,data,value,04111941

The custom log entry, dob, is created in the Add To Log pane of the General settings, and is defined as Name dob, Value {Data.Element.F_Collect_DOB_2.value}, Create After.

Is the substitution formula stripping the leading zero? Something else?

[ptindall · Accepted solution]

Sounds like yet another case of the infamous defect CSCuy80951. It's treating your digit string as an integer. It was fixed in CVP11.0(1)_ES15 so raise a case and ask the TAC for that or a more recent roll-up.

Anyone out there using the digit collection element on 11.0 should apply this one. 

Paul

[sbalmos8089]

Yup, that's what it was again Paul. I ran into that bug, and had the ES, from another customer. I and other guy originally loaded it before I posted this thread. The date read-back started working afterwards, but only the month. Then the call would hang up and the session would be stuck on the gateway. Took both of us a bit of head scratching to remember we had not yet copied over the missing numeric-ordinal wave files into the sys folder (1ord.wav - 31ord.wav). Copy that back over, and everything works. Save for another few burned hours chasing ghosts. *groan*