Поле uniqueid - у всех записей заполнено

да, это поле тоже заполнено

Да, к сожалению
Но зато сама панель стала намного корректнее, теперь видно у кого линия занята и статус сотрудника.
Завтра будем ещё смотреть в коде 1С.
Обязательно отпишусь

Победили проблему.
Итак:
1. К событию не прикреплялся ID звонка, так как время создания события при звонке через Панель телефонии составляло около 3-4 секунд
 1.1 Оптимизировали определение кода города, создав временную таблицу кодов городов при первом обращении и поместили её в менеджер времемнных таблиц
 1.2. Поиск записи в базу MySQL Asterisk шёл 1,8 сек, создали индекс для таблицы PT1C_cdr по полю uniqueid, поиск стал осуществляться за сотые доли секунды. Таблица содержит миллионы записей!
После этого время создания события сократилось до 1-1,5 секунд и ID стал прикрепляться.

2. Проблема с генерацией событий при переключении звонка решается автоматической записью события сразу после его создания и заполнения данными.

3. У нас для входящих вызовов используются Очереди в Астериск. При это поиск записи разговора по частичному ID (до точки) с выдачей LIMIT 1 - выдаёт в большинстве случаев несуществующее имя файла записи разговора (допустим в группе 10 номеров, пришёл звонок, взял трубку 1 номер, а в выдаче может быть любой из 9-ти оставшихся номеров к ID которых не привязан файл записи). Решается поиском по полному ID (с точкой и цифрами после неё)
 3.1. Также выяснилось что компонента ищет по полю uniqueid, а эвышеозначенную проблему можно было бы решить поиском по полю Linkedid (оно одинаковое для всех записей uniqueid звонка), но это реализовать можете только Вы, как разработчики.

4. При совершении исходящего вызова из события или карточки контрагента искать заново набираемый номер не имеет смысла, так как мы чётко знаем кому звоним. Поэтому вместо поиска номера реализовали привязку звонка к конкретному контактному лицу чем добились отсутствия ненужного поиска и ОДНОЗНАЧНОГО определения ПРАВИЛЬНО контрагента и контактного лица даже если у нескольких контрагентов/контактных лиц указан одинаковый номер.

Алексей, добрый день!

Всё таки не удаётся победить повторные генерации/открытия событий при переводе звонка.

Получается что при переводе звонка срабатывает событие Bridge, НО данные XML фильтруются по начальному звонку и соответственно 1С не понимает что перевод звонка это не новый вызов. Отловить это можно было бы анализирую channel1 и channel2, в них при переводе есть запись xfer. Но опять же из-за фильтрации по изначальному звонку - отловить нереально.

Можете что-нибудь посоветовать?

P.S. Для обработки входящих используем Очереди звонков

К сожалению эти советы никак не помогли побороть создание событий.
Пришлось решать это средствами 1С.