Коллекция таблиц

[katja]

Сложилась такая ситуация. Есть рабочая компания со справочниками и проводками, вдруг решили сделать еще одну компанию и объединить их в виртуальную. Коллекция таблиц будет состоять, к примеру, из Клиенты, Поставщики, План счетов, Номенклатуры, Параметры настроек. Получается те записи, которые есть в рабочей компании, нужно чтобы стали общими. Для этого есть 2 пути: либо перегружать таблицы, либо написать скрипт, который поменяет код компании в нужных таблицах. На мой взгляд более простой 2-ой путь, но есть мнения, что он повредит целостность базы. Кто что думает по этому поводу? :о)))

[George Nordic]

На мой взгляд, изменение скулем кода датаэрии не должно сказаться на целостности справочных данных. Вы ж не InventTrans там меняете или LedgerTrans. А вот с планом счетов надо поосторожнее - смотрите, что бы он совпадал еще до объединения. Иначе черевато.

Эх... сначала надо было думать... вот так всегда... Новое требование и пол-архитектуры к чертям. А уже и данные набиты.

С Уважением,
Георгий

[glibs]

Проблема в том, что с т.з. RecID виртуальная компания организована также, как и реальная. Если вы прсто измените DataAreaID в записи таблицы, то это несколько рассогласует мнение системы о том, какой диапазон RecID нужно использовать (см. табличку SystemSequences) с тем, что есть на самом деле. Проблема в данном конкретном случае, конечно, не непобедимая...

В общем дело вкуса. Я предпочитаю не искать проблемы на свою голову там, где их можно обойти. Тем более, что речь идет о справочниках, а значит объем экспорта-импорта маленький.

[katja]

Речь идет конечно о справочниках, но дело в том, например, что в справочнике Клиенты по клинтам уже есть проводки. И таких клиентов перегружать помоему это НЕ ОЧЕНЬ ПРАВИЛЬНО!!!! Какие мнения? Опять же будут проблемы с теми спрвочниками где записи связываются по recId, конешно это решаемо но разве не проще поменять код компании в таблицах?

[George Nordic]

Хм... Дело в том, что, как правильно подметил Глеб, у нумерация RecId у разных компаний ведется независимо. А а клиентам по RecId привязан.. ну, навскидку, альтернативный адрес - это точно. И еще что-нибудь может. Так что, если включите данные с проводками, то тогда поменяйте последний RecId в SystemSequences на мах последний, включенный в данную группу для этой компании.

Екатерина Сергеевна, свяжитесь со мной по почте, ок?

С Уважением,
Георгий.

[ppson]

Екатерине Сергеевне лучше забить вообще на клиентов.
В той компании в которую она дублирует записи, будет всего один клиент.
И поставщик будет тоже один.

[katja]

В той компании в которую они дублируют записи Клиенты не будут в коллекции а вот поставщики будут, потому что там не один поставщик! И что делать с поставщиками?

[Михаил Андреев]

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

[komar]

Цитата:

Изначально опубликовано George Nordic
Хм... Дело в том, что, как правильно подметил Глеб, у нумерация RecId у разных компаний ведется независимо. А а клиентам по RecId привязан.. ну, навскидку, альтернативный адрес - это точно.

А выгрузить вместе с альтернативным адресом, и потом вместе же загрузить? Рассыплются ссылки?

[George Nordic]

Если импорт/экспорт идет через *.csv файл, то аналитика и, кажется, ссылки по RefRecId рассыпаются. Не раасыпется, если через *.bin файл сделать.

C Уважением,
Георгий