Можно пригласить специалиста...

Оставить справочник поставщиков какой есть. Только двойников скинуть куда-нибудь отдельно.
Подчиненый справочник к поставщикам для указания менеджеров, которые с ним работают.

(3) Вариантов много, задача простая, не забудь унифицировать поле СотовыйТел, ну, там, поубирать пробелы, черточки, скобки и пр. А то могут одинаковые телефоны быть записаны по-разному.

(2) Только подчиненый менеджерам

(6) Согласен. Так проще и быстрее получать список поставщиков менеджера .

абсолютно по барабану, быстройдействие в этом вопросе ни играет никакой роли - будет ли данные выбираться за 0.05 сек или за 0.08 сек 0 апсолютно непринципиально... здесь имхо надо идти по пути обеспечения прозрачности схемы данных и удобства работы менеджеров... то, что делить поставщиков по менеджерам в виде когда один поставщик дублируется - стопудово бяка.. - потенциальная проблема...

Опиши более подробно структуру своего первичного справочника Поставщиков и как реализована авязь с менеджерами, потому что возможны разные варианты, например, отдельный реквизит Менеджер или подчиненный Менеджеры или еще как.. и структуру того, что хочешь получить. От этого будет зависеть алгоритм.

(8) Ну на 30к клиентов цифры могут и сильнее отличаться. Тут просто ему надо определится что ему чаще будет требоваться : Список клиентов менеджера или список менеджеров клиента. Ну и онтношение между ними: один к одному, один ко многим.

Вернее один ко одному это фигня какая-то. Один ко многим и многие ко многим.

(13) 1. Получается, должны быть дублированные записи, отличающиеся только Менеджерами.
    2. Что хочешь на выходе
      2.1 Поставщики, у них подчиненные Менеджеры или
      2.2 Менеджеры, у них подчиненные Поставщики.
Вариант 2 зависит от дальнейших алгоритмов, наверное 2.2 предпочтительней, как выше об этом говорилось.

(15) Да, но у тебя во втором справочнике будут опять дубли типа

ссылкаП1 ссылкаМ1
ссылкаП1 ссылкаМ2
ссылкаП1 ссылкаМ1
ссылкаП2 ссылкаМ2 и т.п.

какой тип отношения поставщик - менеджер?
один к одному, один к многим, многие к одному или многие к многим?

(15) подчиненный справочник к справочнику контрагентов не предлагать? (по аналогии с договорами).

(15) можно вместо второго справочника сделать справочник поставщиков менеджера - подчиненный справочнику менеджеров - тогда в нем можно обойтись только ссылкой на поставщиков.
правда, при распределении поставщика новому менеджеру нужно проверить, чтоб он не был уже закреплен за кем-то из менеджеров - то есть перебрать всех. в случае "плоского" (не подчиненного) справочника это сделать проще.

(19) Подчинение - элегантная связь между двумя справочниками. Штатные механизмы успешно решают задачу "показывать только своих" или "показывать всех".

(21) Еще наводящий вопрос.
Какой реквизит обеспечивает уникальность Поставщика(МобТелефон, ОКПО или еще что-то), то же самое относительно Менеджера.
Код не проходит, Наименование тоже не всегда желательно(Большие, маленькие буквы, лишние пробелы, сокращения и пр.), МобТелефон - сомнительно, а если у него несколько телефонов, то опять будут дубли.

(23) У Менеджера тоже ОКПО? Вряд ли.
Если у Поставщика ОКПО, то что делать, если у него несколько м.тел.
Ведь они все должны быть известны Менеджеру.

(22), (23) ну об уникальности менеджеров можно не сильно заботиться, если это свои сотрудники (только ограничить права создания новых элементов и редактирования существующих), а поставщиков - в подчиненный справочник с контролем уникальности по ИНН.

(25) Но "свои" тоже должны по чему-то контролироваться на уникальность, по идее, если это Сотрудники, то ИНН. Иначе, всякое бывает, например, смена фамилии(вышла замуж) - Наименование изменилось, а Менеджер остался прежним.
И все же вопрос по нескольким телефонам, по идее это или подчиненный к Поставщикам справочником или поле строка, большой длины с регламентированным заполнением, например, через ";". Сейчас это не решено, где видится решение?

(26) так как с моб.телефонов уникальность снимается в пользу ИНН (сначала заполнить в старом справочнике, потом переносить в новый) - думаю, хранить их можно как автору заблагорассудится, в зависимости от того, как планируется использовать.

(27) Это я понимаю, но Автор помалкивает, а от всего этого зависит алгоритм преобразования 1->2(или больше?).