Transfer-problem operator

[nschreuder]

For some of our operators (OWS) it's sometimes not possible to transfer a call to an ACD-group with an entirly occupied queue, although there is a CDINI from this ACD-group to another ACD-group with more than enough space in it's queue. The operator gets "busy" and is not allowed to tranfer the call. What could be the cause of this? Who can help me out? We have BC12SP11.

T.i.a.

 

[whosrdaddy]

how is the sel parameter og your acd group?

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[nschreuder]

Whosrdaddy,

Thank you for responding

SEL of (problem)group = 01060
SEL of (CDINI) group = 11060

 

[nschreuder]

Please ...?

 

[whosrdaddy]

nccoi,

It is not really clear for me what the problem is here.

are you absolutely sure about the queue not full when the problem arises? try to simulate the problem. monitor ACD whith ACCSP:GRP=x;

Cheers,
Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[nschreuder]

Whosrdaddy,

Thank you for responding.

I'm absolutely sure the queue of the second ACD-group is not full. And it's obviously an operator-problem, maybe an OWS-problem, because when i transfer a call with a DTS to the first ACD-group it arrives perfectly in the queue of the second ACD-group. It works fine, so no problem.
To simulate the fault is difficult because the fault appears for, say, half an hour and than it's gone. Monitoring with ACCSP tells me there is nothing wrong. CCM Information Manager tells me there is nothing wrong. But operator is still complaining they cannot transfer calls.
We work with BC12SP11, but i don't think it's relevant because the problem appeared already in SP6. We hoped it would be gone with SP11, but it isn't.

Thank you.

 

[whosrdaddy]

how are the calls coming to the OWS? maybe there is a specific call case having this problem

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[TeleLion]

What value does you PARNUM = 254 have?

To MD or not to MD that is the question

 

[patcher]

I think you need to SP upgrade your DNA/OWS. We have the same issue and its fixed now.

If you will trace it, STUNI:LIM=X,UNIT=OLP1T; when the operator extend the call. You will not get any key pressed or extend key pressed from EQU. Or probably different key inforamtion from EQU that is why OLP1T is not doing anything to process extending. I don't really 100% sure what we've done to fix our problem but I am certain I did not do anything in the MD110 side. And I can remember I told our Application Engineer to upgrade DNA/OWS.

 

[nschreuder]

Whosrdaddy:
They are normal external incoming calls.

TeleLion:
<aspaparnum=254;
APPLICATION SYSTEM PARAMETERS
PARNUM PARVAL
254 0

Patcher:
We have DNA5.2_SP4. As far as i know it's the latest version.

 

[GFDANNHAUSER]

Nccoi

Hi the latest is DNA5.3 sp1

Regards

 

[nschreuder]

Gfdannhauser,

Thanks, but in the mean time i figured it out, yes.

 

[Mpe]

This is just a thought.
Do you have a entry in the DMG database concerning these ACD groups.
I.e can the operator search and get a name and number in the OPI.

 

[nschreuder]

Mpe:
Yes, using OWS they can search and find the numbers of the ACD-groups, NOT the numbers of the extensions. Do you think DNA has something to do with our problem? You make me curious.

T.i.a.

 

[datatek]

i had the same problem with a bc11 and a ows, update of the dna platform to dna5.3sp1 solved my problem

 

[nschreuder]

Hi guys,

Well, it took a while but we found the cause of our problem. (How weird do you wanna have it?)

It's a DNA-problem. The second ACD-group was in DMG disabled to be searchable in OWS.
Enabling this option solved the problem....

Thanx for all your interventions.