При работе с конфигурацией 1С:ERP Управление предприятием 2.4 разработчики часто сталкиваются с необходимостью программного доступа к данным контактных лиц или анализа структуры базы данных на уровне SQL. Архитектура ERP в этом вопросе несколько сложнее, чем в старых версиях УПП, из-за разделения понятий управленческого и регламентированного учета. Разберем подробно, где именно хранятся эти данные на разных уровнях системы.
Прежде всего, проанализируем структуру объектов в конфигураторе. Основным «контейнером» для хранения информации о людях, с которыми ведется взаимодействие со стороны контрагентов, является справочник КонтактныеЛицаПартнеров.
Важно помнить следующие ключевые моменты:
Партнеры. Это фундаментальное отличие ERP — контактные лица привязаны к управленческим сущностям (партнерам), а не к юридическим лицам (контрагентам).Контрагенты и КонтактныеЛицаПартнеров на уровне метаданных не существует.Рассмотрим архитектурную особенность: справочник КонтактныеЛицаПартнеров часто выступает в роли «прослойки». Основные персональные данные человека (ФИО, пол, дата рождения) могут дублироваться или храниться в связанном справочнике ФизическиеЛица.
Это сделано для реализации сквозного учета. Посмотрим на ситуацию: один и тот же человек может быть контактным лицом в компании «А», контактным лицом в компании «Б» и при этом являться штатным сотрудником вашей организации. Чтобы не плодить дубликаты персональных данных и соблюдать требования по защите персональных данных, система связывает объект контактного лица с карточкой физического лица.
Выясним, где именно лежат номера телефонов и почтовые адреса. В 1С:ERP 2.4 используется подсистема «Управление контактной информацией». Данные хранятся в табличной части КонтактнаяИнформация самого справочника КонтактныеЛицаПартнеров.
Особенности хранения в ТЧ:
Для программного извлечения этих данных рекомендуется использовать функции общего модуля УправлениеКонтактнойИнформацией, а не прямые запросы к табличной части, чтобы корректно десериализовать XML.
Если возникла задача проанализировать данные напрямую в СУБД (например, через SQL Server Management Studio), нам нужно знать имена физических таблиц. Проанализируем пример структуры (обратите внимание, что индексы таблиц Reference и VT могут отличаться в вашей конкретной базе):
Reference180 (здесь хранятся ссылки, наименования и основные реквизиты).Reference180.VT4753.Reference180.VT4768.Reference180.VT4771.Важное предупреждение: Никогда не полагайтесь на статичные номера таблиц (типа 180 или 4753). Они генерируются платформой динамически при обновлении конфигурации. Чтобы выяснить точные имена таблиц именно в вашей базе, выполните следующий код в консоли кода:
Структура = ПолучитьСтруктуруХраненияБазыДанных("Справочник.КонтактныеЛицаПартнеров", Истина);
Для Каждого Строка Из Структура Цикл
Сообщить("Таблица: " + Строка.ИмяТаблицыХранения + " — " + Строка.Назначение);
КонецЦикла;
Помимо жесткой привязки к владельцу-партнеру, в ERP существует механизм связей. Рассмотрим ситуацию, когда контактное лицо влияет на решения в нескольких компаниях холдинга. Эти данные могут не ограничиваться справочником, а фиксироваться в регистре сведений СвязиМеждуПартнерами. Это позволяет CRM-системе строить дерево отношений и видеть истинное влияние персоны на бизнес-процессы.
Физически ссылка на объект СправочникСсылка.КонтактныеЛицаПартнеров записывается в реквизит КонтактноеЛицо практически во всех цепочках продаж и закупок. Проанализируем список документов:
ЗаказКлиентаКоммерческоеПредложениеКлиентуПриобретениеТоваровУслугВзаимодействие (Звонки, письма, встречи)В подсистеме взаимодействий контактное лицо является ключевым объектом для построения истории отношений. Все записи о коммуникациях содержат физическую ссылку на этот справочник, что позволяет в карточке партнера видеть полную ленту событий по каждому его представителю.
Таким образом, для полного поиска «физического расположения» данных нам нужно учитывать связку: Справочник (Метаданные) -> Таблицы SQL (Данные) -> Табличные части (Контактная информация) -> Физические лица (Персональные данные).