1с перенести контактную информацию

Обновлено: 07.01.2025

Сначала нужно перенести один в один регистр сведений КонтактнаяИнформация БП 2.0 в, сохраненный фирмой 1С специально для переноса, регистр сведений УдалитьКонтактнаяИнформация БП.3.0.

Затем уже, работая в одной базе БП.3.0, перенести сведения из регистра сведений УдалитьКонтактнаяИнформация в табличные части соответствующих справочников (мне нужно было перенести только данные контрагентов поэтому в моем случае это был Справочник.Контрагенты).

Описание процецсса:

1) Первый этап нужен для более простого и быстрого, на мой взгляд, переноса, т.к. перенос один в один это довольно несложная задача:

- можно воспользоваться типовой обработкой ВыгрузкаЗагрухкаXML.epf (в базе 3.0 также имеется такой же регистр КонтактнаяИнформация).

- либо быстренько накидать правила обмена данными, чем я и воспользовался. (внизу прикреплены мои правила обмена из БП 2.0 в УХ 1.2 для переноса контактных данных контрагентов).

2) В БП 3.0 есть общий модуль ОбновлениеСПредыдущейРедакции, а в нем есть процедура ПереносКИПриОбновленииС20(), так вот в ней все написано как раз для переноса из регистр сведений УдалитьКонтактнаяИнформация в табличные части.

Так вот копируем себе в обработку эту процедуру поднастраиваем по себя и вперед. (Прикрепил ниже подправленную обработку для конечного заполнения табличной части справочника Контрагентов контактной информацией).

Уточню, что содержимое каждой строки табличной части определяется Типом и Видом контактной информации, также имеется хитрый реквизит ТЧ который теперь содержит всю информацию адреса в XML виде, вот с ним могут возникнуть трудности.

Если у вас контактная информация хранилась в произвольной форме, т.е. не в соответствии с КЛАДР, то это простой вариант, в обработке ниже как раз использовался он. Для более сложного варианта преобразования данных в XML формат в базе имеется процедура: УправлениеКонтактнойИнформацией. КонтактнаяИнформацияВXML, вот с ней уже нужно будет разобраться.

Была очень сильно дописанная БП 2.0, необходимо было осуществить переход на УТ 11. В плане конвертации контактной информации было относительно просто: посмотрел, как это осуществлено в типовой конфигурации, сделал также - готово. Однако, незадача - адреса переносятся все "в свободной форме", как и остальное, а нужно, чтобы переносилось "красиво".

Задача: перенести контактную информацию из регистра сведений в табличные части объектов без потери "разбиения по заполнению", т.е. чтобы номер дома в пользовательском интерфейсе был на своем месте (в поле "Номер дома"), как и добавочный номер и т.п.

Допущение: правила конвертации для видов контактной информации уже написаны и работают как надо. Конфигурация-приемник имеет общие модули РаботаСАдресамиКлиентСервер, УправлениеКонтактнойИнформациейСлужебныйПовтИсп, УправлениеКонтактнойИнформацией (если конфигурация-приемник типовая, 99% что они есть).

Далее по тексту: КИ - контактная информация.

Поскольку в той базе, которую необходимо перенести, КИ есть лишь трех типов (адрес, email, телефон), рассматривал я только их, однако, полагаю, что и этой информации будет достаточно в 90% случаев.

Структура КИ старого формата.

Общие для всех типов КИ:

Тип - ПеречислениеСсылка.ТипыКонтактнойИнформации - Сам тип КИ.

Вид - СправочникСсылка.ВидыКонтактнойИнформации - Вид КИ, может быть создано сколь угодно.

КИ типа Адрес:
Поле1 - Строка - Индекс, т.е. "658702".
Поле2 - Строка - Регион, т.е. "Алтайский край".
Поле3 - Строка - Район региона, т.е. "Каменский р-н".
Поле4 - Строка - Город, т.е. "Камень-на-Оби г".
Поле5 - Строка - Населенный пункт, т.е. "Плотинная ст".
Поле6 - Строка - Улица, т.е. "Николаева ул".
Поле7 - Строка - Номер дома, т.е. "89".
Поле8 - Строка - Номер корпуса, т.е. "".
Поле9 - Строка - Номер квартиры, т.е. "186".
Поле10 - Строка - Так и не понял, зачем это поле, как бы ни старался заполнять адрес, так и не заполняется :)

КИ типа Телефон:

Если номер заполнен одной строкой, будет заполнено одно из вышеперечисленных полей.

Остальные поля особого смысла не имеют, с той лишь оговоркой, что переносить их все же нужно:

Комментарий - Строка - Собственно, комментарий.

ЗначениеПоУмолчанию - Булево - Нет необходимости переносить.

ТипДома - ПеречислениеСсылка.ТипыДомов - Нам нужно строковое представление поля.

ТипКорпуса - ПеречислениеСсылка.ТипыКорпусов - Нам нужно строковое представление поля.

ТипКвартиры - ПеречислениеСсылка.ТипыКвартир - Нам нужно строковое представление поля.

Структура КИ нового формата:

Структура табличной части объекта, у которого есть КИ:

Тип - ПеречислениеСсылка.ТипыКонтактнойИнформации
Вид - СправочникСсылка.ВидыКонтактнойИнформации
Представление - Строка
ЗначенияПолей - Строка - Строка XDTO
Страна - Строка
Регион - Строка
Город - Строка
АдресЭП - Строка
ДоменноеИмяСервера - Строка
НомерТелефона - Строка
НомерТелефонаБезКодов - Строка
ВидДляСписка - СправочникСсылка.ВидыКонтактнойИнформации
Значение - Строка - Строка JSON

Рассмотрим структуру реквизита "Значение" более подробно. Вся информация хранится в виде строковых представлений.

В общем случае для поля есть три характеризующих значения, их имена формируются следующим образом:

*ИмяПоля* - само поле
*ИмяПоля*Type - сокращение, например, "г.", "с.", "ул.", "край" и т.п.
*ИмяПоля*id - уникальный идентификатор по адресному классификатору.

Общие для любого типа КИ

value - Представление
comment - Комментарий
type - Тип КИ

Поля для типа "Адрес":
country - Страна
countryCode - код страны
addressType - Тип адреса, если заполняется автоматически из адресного классификатора - "Административно-территориальный",
если заполнен вручную, но не одной строкой - "Муниципальный", если одной строкой - "ВСвободнойФорме".

Если тип адреса задан в свободной форме, все поля, расположенные ниже, не заполняются.

ZIPcode - индекс
area - Регион страны (как субъект РФ)
areaType
city - Город
cityType
street - Улица
streetType

если есть модуль РаботаСАдресамиКлиентСервер:
id - уникальный идентификатор
areaCode
areaId
district - Район
districtType
districtId
munDistrict - Муниципальный район (только если тип адреса - Муниципальный)
munDistrictType
munDistrictId
cityId
settlement - Поселение (только если тип адреса - Муниципальный)
settlementType
settlementId
cityDistrict - Внутригородской район
cityDistrictType
cityDistrictId
territory - Территория (только если тип адреса - Муниципальный)
territoryType
territoryId
locality - Населенный пункт
localityType
localityId
streetId -
houseType - тип дома
houseNumber - номер дома
houseId
buildings - тип корпуса, массив с полями type, number
apartments - тип квартиры, массив с полями type, number

Поля ниже заполняются только при заполнении адреса по классификатору:
codeKLADR
oktmo
okato
asInDocument
ifnsFLCode
ifnsULCode
ifnsFLAreaCode
ifnsULAreaCode
stead
steadId
Значения для всех полей - строковые, однако, поля buildings и apartments заполняются в виде массива следующим образом:
"buildings": [
"type": "Корпус", // Тип корпуса
"number": "1" // Номер корпуса
>

Поля для типов "Телефон" и "Факс":
countryCode - код страны
areaCode - код города
number - номер
extNumber - добавочный номер

Вся суть нового формата заключается в реквизите Значение, который в формате JSON хранит всю информацию. В БСП уже есть функции, которые очень сильно помогают по работе с данным полем, к тому же, по значению данного поля могут быть заполнены все остальные реквизиты табличной части, поэтому, для выполнения задачи требуется получить значение лишь этого реквизита.

В общем случае код процедуры переноса КИ будет выглядеть примерно следующим образом:

Получаем данные в "старом" виде.
По виду КИ получаем структуру, в которой содержатся все возможные поля для данного вида КИ.
Заполняем структуру.
По заполненной структуре формируем строку JSON и заполняем остальные поля табличной части КонтактнаяИнформация (этот пункт уже реализован в БСП).

Алгоритм совсем не сложный, сложно было разобраться, какие именно поля необходимо заполнять.

В начале хотел прикрепить к публикации правила конвертации для КД 2.1, однако, решил, что проще будет прикрепить обработку, на которой можно алгоритм протестировать, ведь тому, кто знаком с Конвертацией данных, будет несложно добавить алгоритм в обработчики, а тому, кто с ней не знаком - несложно переделать обработку (например, добавить COM-соединение с нужно базой, брать данные по множеству объектов и заполнять также множество объектов). Она, скорее, дополнение ко всему вышесказанному, нежели суть статьи.

В обработке необходимо указать ссылку на объект, в который загружается КИ, а также указать саму КИ.

Для удобства и ускорения загрузки КИ можно воспользоваться табличным документом.

Для этого можно в консоли запросов получить данные, вывести их в табличный документ, а затем копипастом вставить в обработку. На вкладке "Контактная информация" нажать кнопку "Заполнить из табличного документа" и вручную указать те виды КИ, которые не нашлись по наименованию.

После того, как заполняемый объект выбран и табличная часть заполнена, необходимо нажать кнопку "Загрузить контактную информацию", после чего КИ будет добавлена в выбранный объект.

Алгоритм тестировался на платформе 8.3.15.1489, конфигурация УТ 11.4.11.104 с версией БСП 3.0.3.272.

Описание процецсса:

I. Решение задачи для для конфигураций на платформе 8.2, обычных форм, Бухгалтерии 2.0

пример кода для выбора адреса из Контактной информации:

II. Решение задачи через СписокЗначений для конфигураций на платформе 8.3, управляемых форм, Бухгалтерии 3.0

пример кода:

Получившийся выпадающий список адресов:

(мне показалось неудобным искать адрес, если данных в регистре много, поэтому предлагаю другой вариант ниже)

III. Решение задачи через ФормуВыбора для конфигураций на платформе 8.3, управляемых форм, Бухгалтерии 3.0

III.1.Что нужно сделать в форме-приемнике (форме Владельца)

У нас есть некая табличная часть. В один из её реквизитов мы хотим добавить адрес контрагента, используя форму выбора адреса. В моем примере это "ТабличнаяЧасть1" с реквизитом "Адрес" типа Строка. Соотвественно в моей обработке есть и сам реквизит "Контрагент" типа СправочникСсылка.Контрагенты. Важно не забыть добавить кнопку выбора.

Дальше объявляем у Адреса событие НачалоВыбора. В диалоговом окне выбираем только "на клиенте"

В этом событии должен отработать следующий код:

III.2.Что нужно сделать в форме-источнике

Дошли до формы выбора адреса. У меня получилась такая простенькая форма:

Нам понадобятся два реквизита СпрОбъект (тип СправочникОбъект.Контрагенты) и соответственно СсылкаКонтрагент. Вытаскиваем (перетягиваем) на форму Табличную часть "Контактная информация" у СпрОбъект и ничего заполнять не надо, просто в дальнейшем получим объект у СсылкаКонтрагент и информация будет отражаться на форме.

Что необходимо сделать в модуле формы выбора:

Во-вторых, получим объект у Контрагента, чтобы заполнилась табличная часть Контактной информации на форме

В-третьих, у табличной части объявляем событие "Выбор" только "на клиенте" и добавляем ОповеститьОВыборе

III.3.Что еще нужно сделать в форме-приемнике

Объявить процедуру ОбработкаВыбора только "на клиенте" и вставить подобный код:

III.4.Как записать изменения Контактной информации из формы выбора

Как видно из рисунка выше, у меня объявлена Команда формы - ЗаписатьИзменения. На ней "висит" следующая процедура:

IV. Вопрос к Знатокам- "Баг или криворук?"

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

Вопрос очень простой: Что же делать, как же быть в такой ситуации?

Покопавшись самостоятельно, удалось найти, что в самых свежих релизах Бухгалтерии 3.0 такая ошибка не воспроизводится. Разработчики добавили реквизит формы типа "Булево" (у меня это АдресЗаполнено, у них это АналитикаУчетаЗаполнена) и его в ОбработкеВыбора исходной формы заполняют. НО если (с учетом этого добавления) запустить мою обработку на старом релизе - строчка пропадет, если на новом - останется. Платформу при этом не меняем. В связи с этим, всё равно хочется докопаться до сути. КАК при одной платформе, но разных релизах один и тот же код отрабатывает по-разному, учитывая, что никакие общие модули не используем?

Читайте также: