Здравствуйте!

В виду того, что в версии 2.0 архитектура была изменена весьма значительно, на текущий момент готового алгоритма обновления не существует.

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

По мере готовности такой утилиты - будет сделано дополнительное сообщение.

Здравствуйте!

Просьба писать новые комментарии - таким образом к нам приходят уведомления. Иначе мы просто пропустили изменение в Вашем каменте и по этой причине он остался без ответа. 

Да, конечно же мы можем это сделать...
Оценочная трудоемкость 3 ч/часа (включая внесение изменения в процедуры удаления и объединения контрагентов). Цена одного ч/часа = 1.350 рублей.

Пришлите, пожалуйста Ваши реквизиты для выставления счета на vav@axistem.ru и менеджер согласует с Вами документооборот по задаче и процедуру технического взаимодействия. 

Первый вариант требует программирования только триггера, пусть и не самого тривиального, но все равно не так много. При этом архитектура данных получается реальной и с ней можно работать в Дизайнере интерфейсов и использоваться в отчетах. Кроме того, по сравнению со вторым вариантом - метод менее ресурсоемок на этапе формирования интерфейса пользователя, т.к. не требует вычислений. Так же придётся добавить работу с таблицами структуры в процедуры удаление и объединения контрагентов - иначе ошибок поймаем.

Второй вариант требует более сложного программирования - написания функции, которая без добавления дополнительных сущностей в архитектуру БД, будет формировать таблицу требуемого вида. Данный вариант при сложной структуре связей и большом кол-ве вложенностей в холдингах будет требовать больше вычислительных ресурсов сервера при формировании реестра контрагентов и может "подтормаживать" (особенно на SQL Express). Но при этом не придётся дополнительно редактировать процедуры удаления и объединения контрагентов.

Я бы рекомендовал путь с триггером. 
но любой их вариантов потребует от вас знаний Transact-SQL.

Ещё раз здравствуйте!

Методологии решения задачи получается несколько:

Вариант первый...

Конфигуратор
1. На карточку контрагента (класс "Контрагенты) добавить атрибут "Входит в холдинг" - ссылка на контрагента

2. Создать новый класс "Структура холдинга" (в нём будем хранить глубину вложенности и структуру отступов с номерами):
  - Холдинг (ссылочный на Контрагенты - самый верхний уровень, куда входит, обязательный)
  - Подразделение (ссылочный на Контрагенты - текущий уровень, куда входит, обязательный, по умолчанию равен верхнему уровню)
  - Контрагент (ссылочный на Контрагенты - кто входит, обязательный)
  - Отображение (строка, где будем вычислять отображаемый в дереве формат)

3. На карточку контрагента (класс "Контрагенты) добавить атрибут "Подразделение холдинга" - ссылка на класс "Структура холдинга".


Дизайнер интерфейсов
1. В реестр контрагентов добавить вкладку "Холдинг"

2. Добавить таблицу с классом контрагенты, где указать зависимость через обратную ссылку на  атрибут Холдинг в основной таблице Контрагентов. Это позволит в отдельной таблице дизайнера интерфейсов видеть верхний уровень всей структуры.

3. На вкладку Холдинг разместить таблицу и в ней отобразить класс "Структура холдинга" с атрибутом "Отображение". Эту таблицу сделать зависимой от таблицы, созданной в п.2 по атрибуту холдинг. Таким образом неважно на какую часть структуры встанет курсор в основной таблице - на вкладке всегда будет отображена вся структура.

Особенности реализации
Необходимо написать триггер, который при указании ссылки на холдинг будет создаться запись в классе "Структура холдинга" с вычисленным кол-вом отступов и ссылками на контрагента и самый верхний уровень холдинга.


Вариант второй...

Конфигуратор
1. На карточку контрагента (класс "Контрагенты) добавить атрибут "Входит в холдинг" - ссылка на контрагента.

2. Разработать виртуальный класс, где формировать вывод структуры с рекурсией вложенности  и с зависимостью от каждого участника холдинга. 

Ещё раз, здравствуйте!

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

1. Компания_1
2. Компания_2
   2.1 Компания_3
   2.2 Компания_4
3. Компания_5
   3.1 Компания_6

Как видно иерархия вложенности определяется отступами (пробелами в начале строки) и порядковым номером.

Теперь следующие вопросы: 
 - может ли одна компания в ходить в структуру различных иерархий (холдингов)? 

 - когда в реестре контрагентов выделена Компания_2 (см. мой пример выше), то каким образом для ней должно выглядеть содержание вкладки "Холдинг" ? Только компании 3 и 4 или необходимо для всех участников холдинга отображать полную структуру всего холдинга?

Когда я интересовался вариантами использования информации - речь шла о уже реализованных аналитиках (количественных и суммовых), которые сейчас отталкиваются от каждого отдельного контрагента. В случаях с холдингами, как правило, возникает желание видеть картину как по холдингу в целом, так и по отдельным его участникам. А это накладывает весьма экзотические требования к эргономике интерфейсов и логике аналитик. Если таковых потребностей, то задача сводится к реализации интерфейса справочного представления иерархических взаимосвязей. Это решаемо. :)

Здравствуйте!

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

Следующим значимым аспектом, который повлияет на метод решения задачи - является способ использования данной информации, а именно - где и в каких отчетах/интерфейсах она должна отображаться и в каком виде?

Как только будут конкретизированы требования - можно будет разбирать этот наглядный пример.

Здравствуйте!

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

Оптимальным является импорт в промежуточную таблицу из которой производить разбор и запись задач уже средствами SQL-процедуры. Это потребуется затрат времени на программирование и создание класса промежуточной таблицы, но зато позволит на гибкую логику вынести контроль и формирование необходимых ссылок любого уровня вложенности.