Account code custom application ((Any ideas?))

[mduman]

We are attempting to implement account codes in our IPT environment, but we have run into a few snags.

We have some pretty stringent requirements, and I wanted to know if anyoine else has had any experience with this.--I'm sure that I can't be the only one with issues like this :-)

What we need:

*Users should have the option to enter an optional account code to charge the call

*The account code should support up to 15 characters

*The code can consist of characters available on the telephone key pad which include 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, *, and #

*The ‘*’ is used as a delimiter

* The account code entry function should be available at the start of the call (the code could additionally be entered anytime during the call)

* It is preferred that this is a softkey function rather than through the Services facility (i.e handset is lifted an softkey options change to include account code)

* The account code is required to be stored in a field within the CDR record for the call

Account code does not need to be verified and should not be need to be defined with CallManager (i.e. route pattern dependency, etc)

Thanks in advance for any help, input, best wishes, etc.

-Mike

[CHRIS KALETH]

I created a separte "Charge Line" Partition and Calling Search Space and create a DN number on each users phone that uses these. Then I created a rt pattern of 9.@xxxxxxxx (we have 8 digit code) using a PreDot-Trailing #

This worked for one office but when implemeting another office (different carrier) I am having problems getting them to ignore the extra digits. Also, other ways I found (code before the 9) did not capture the call in the CDR. This may not meet all your requirements but hopefully it helps. Let me know if you find any additional ways.

ckaleth@zsassociates.com

Thanks,

[aaronw.ca]

ckaleth, did you configure digit discarding to get rid of the extra digits before sending the call out the gateway? Make sure you use route list discarding and not route pattern discarding. The digits that are sent to CDR are the digits after route pattern processing, but before route list processing. That way you can ensure the digits end up in the CDR but are not sent out the gateway.

As an alternative to the charge line partition, you could add another route pattern that begins with a digit that none of your extensions start with (such as 8), for example: 8.XXXXXXXX@. Then you can still have the 9.@ pattern for regular calls. You could use pre-dot discarding on the route pattern and pre-@ discarding on the route list, though you might not want to discard the leading access code (ie the 8) on the route pattern as that makes it easier to identify account code calls in CDR.

Just some thoughts... not sure if that helps!

[james.a.bond]

www.litescape.com

What we need:

*Users should have the option to enter an optional account code to charge the call

--You have the option to turn validation on/off

*The account code should support up to 15 characters

--The Cisco CCM currently supports 24 dialed digits which will limit your ability to dial account codes + number in one string. We have this feature but be aware of this limitation.

*The code can consist of characters available on the telephone key pad which include 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, *, and #

--This is a native feature

*The ‘*’ is used as a delimiter

--This is also a native feature

* The account code entry function should be available at the start of the call (the code could additionally be entered anytime during the call)

--Refer to above comment on CCM dialed digit limitation. There is an IVR option to prompt for account code.

* It is preferred that this is a softkey function rather than through the Services facility (i.e handset is lifted an softkey options change to include account code)

-- Once the call is dialed we push a form to the phone.

* The account code is required to be stored in a field within the CDR record for the call

Account code does not need to be verified and should not be need to be defined with CallManager (i.e. route pattern dependency, etc)

--Call Records are stored in separate SQL database and synched with CCM CDR for billing system integration.

[ckatene]

don't know if this could help, but we have a product which is an IP phone XML app. it simply allows a user to enter a numeric PIN, and, based on what the PIN is alters the phone's calling search space for a predetermined amount of time. In addition, the date and time that the PIN was activated and deactivated is written to a local SQL table. this works with our CDR accounting package, which extracts CDRs from the CallManager and adds another field which is used to identify CDRs that refer to calls made from phones with a PIN active.

This app was developed to provide PIN-based dialling, but can be used for account codes as well.

if you'd like information, email us: info@nzice.com

callum

[aaronw.ca]

It looks like the built-in account code functionality on 3.3(4) and 4.1 (CMC) won't fit your requirements as the code cannot be entered after the call but must be entered at the time of the call and the codes must be pre-defined in CallManager.

Otherwise it's not a bad fit if you use two route patterns (ie use access code 8 for outgoing calls using account code, or use 9 for outgoing calls with no account code) or partitions/css. The account code is inserted directly into its own field in CDR which is nice, as well as its seamless integration with CallManager.

External solutions generally merge the account code with dialed digits (so the code is stored directly with the CDR record) or in an external location that must be merged with CDR at a later date.

Best of luck!

Cisco CMC/FAC:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_3/sys_ad/3_3_4/ccmfeat/fsfaccmc.htm