Изменение существующей виртуальной компании

[mazzy]

Цитата:

Сообщение от kashperuk

Хотелось бы на всякий случай уточнить один момент:

При изменении существующей виртуальной компании (Конкретно, добавлении еще одной коллекции таблиц), если данные в компании уже были импортированы, достаточно ли простого обновления поля dataAreaId в соответствующих таблицах для соответствующих записей?

Или есть еще что-то, что необходимо сделать?

Спасибо

нет, недостаточно.
1.
что-то нужно сделать с recID. вполне возможно, что в старой виртуальной компании уже использовались recID, которые в новой компании только будут использоваться в будущем. поэтому, как минимум нужно будет сдвинуть next в таблице sysnumebrsequences.

2.
что-то нужно сделать со ссылками на компанию и на recID в другой компании.

2.1. Ссылки на recid
Не стоит забывать, что штатные средства позволяют любую таблицу сделать общей для виртуальных компаний. И это штатное средство Аксапты. Поэтому к области риска относятся все ссылки по RecID.

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

А вообще говоря, к области риска по ссылкам на DataAreaID относятся:

• интеркампани (как журналы, так и заказы/закупки),
• финансовые отчеты (там можно указать другую компанию),
• OLAP отчеты (как стандартные, так и самописные)
• Reporting Service отчеты
• да и вообще все внешние средства доступа к базе и к данным компаний

[Logger]

Цитата:

Сообщение от mazzy

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

Если не ошибаюсь, то в данном случае ничего менять не надо. Если у нас в справочнике dataareaId сменился с кода обычной компании на код виртуальной, то не надо в ссылках intercompany полей перебивать коды с реальной компании на код виртуальной.

В случае же если поменялся код компании с одного на другой (не виртуальной) то конечно нужно перебивать коды.


Кстати, Иван, в ядре давно есть бага, которую никак не вылечат - при переименовании первичного ключа у справочников CustTable, VendTable, EmplTable, LedgerTable, etc в случае если они сидят в виртуальной компании, ядро некорректно переименовывает ссылки на них из LedgerJournalTrans. Виноват relation в котором участвует dataareaId.