Подскажите, есть БП 3.0, необходимо создать подчиненную РИБ, но с так чтоб изначально она была полностью чистая... Такое вообще возможно?

да

(1) Продолжай

кто знает ответ на вопрос (0), кроме как "да"? ))

(3) Нет

ну или как вариант. чистая база из cf + Книга знаний: Альтернативное создание начального образа в УРБД

Хотя смысл не понятен

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

(6) +1
Понятие "чистая" - относительное понятие. Автору нужна копия базы, но без справочников и документов?

(7) ну да, все что нужно я потом в центре "помечу" к выгрузке и синхронизирую... ))

(8) Я бы такую задачу решил. Но... для этого нужно сломать план обмена, а после починить.

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

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

(9) чем вариант (5) не подходит?

Проблема в другом, что в этой "пустой" базе 1С при первом запуске автоматически создать и заполнит кучу классификаторов. И после включения её в обмен она тупо задвоит служебные данные.

Причем классификатор это в том числе и валюта, и единицы измерения и банки и т.п.

В качестве подсказки - в идеале план обменов РИБ должен состоять не из одного Плана, а хотя бы из двух : первый план для обмена метаданными (что и хочет в данном случае ТС), а второй план для обмена пользовательскими данными.
Но типовые так не делают, т.к. слишком высока вероятность ошибок из-за возжможности несовпадения таких планов друг с другом

(10) указанный вариант = КОПИЯ основной, которую превращают в новый подчиненный узел без выгрузки. ТС хочет не копию, а ПУСТУЮ

(9) Имхо, на первый взгляд, все правильно. Изменить состав плана обмена, создать начальный образ. Потом "восстановить" план обмена и сделать взаимный обмен (с миграцией конфигурации). При этом предопределенные данные перенесутся "сами-собой". Галки сносить нужно у всех документов, выборочно справочников (оставить настройки, классификаторы и т.д.). Регистры движений - всё в мусор, регистры сведений - выборочно.

(13) ?
Берем cf и создаем из неё пустую базу. Далее эту базу подключаем к обмену - инструкция подключени по ссылки.
Где тут копия?

И кстати: зря так все боятся удалять все(!) документы - на самом деле это легко и просто :)

(16) в последних типовых? Это нефига не лешки и не просто.
Есть куча служебных справочников (например ключи аналитики затрат, ключи аналитики НДС) Куча РС. И ты сидишь и думаешь что и как удалять.

А если есть ЭДО/1С-Отчетность - то это отдельный трэш

(15) э... ссылка описывает без болезненное подключение копии почему? Потому что в той копии уже есть все нужные УИД.
А при генерации из CF возникнут какие-то новые УИД, особенно для всяких там планов видов характеристик, регистров сведений и т.д. и т.п.

(18) Т.е. мы говорим все таки о копии?

(17) Вах :) Ты с ходу назвал причину почему твой вариант в (5) нерабочий :))

(19) Я говорю, что на сломанном плане обмена действительно можно сделать нужный начальный образ - без лишних данных, но с нужными для правильной дальнейшей работы данными.

+ но затем план обмена надо вернуть в типовое состояние.

Как это правильно на практике делается - у меня такая практика есть :-)

(17) Не знаю для кого как, но для меня совсем не проблема пройтись по составу плана обмена и отделить зёрна от плевел :) Просто одно из двух: или профессионал и знаешь конфигурацию, состав и назначение метаданных, или... "Вон из профессии!".

Т.е. :

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

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

Как-то коряво сказал, но думаю вы поняли мысль :(

(26) Понятно.
Просто я подразумевал сам по себе, что в условиях с большим количеством данных на основной базе вероятна в ней интенсивная дневная работа пользователей, причем самых разных. А с учетом того, что отпочкованный узел нужно сделать "чистым", то всю эту канитель можно безболезненно замутить на любой актуальной копии основной (лишь бы никто в CF этой базы ничего не менял в текущее время) не напрягая юзеров своими манипуляциями в конфигураторе.

Ребята. Все это дело затеяно для перехода после НГ на новую базу, в старой куча не нужных справочников и т.д. и т.п.
Вот и возникла мысля, создать подчиненный узел, перенести в него минимум инфы, но работать пока год не закрыт в старой базе, все созданные документы попадают в новую РИБ, ну а после закрытия года сделать свертку и в созданную РИБ перенести только операции с остатками + подчистить какие нить "хвосты" из старой базы... Хотя, если у кого есть вариант лучше, с удовольствием выслушаю ))

Как хорошо было в 77, грохнул определенные dbf и красота! )))

(28) Нормальный вариант. Как один из способов, вполне себе достойный кандидат на отсекание ненужного вместо свертки.

Но перенести относительно небольшое число свежих документов можно и другим, менее экзотическим и более распространенным способом.

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

А из всей так называемой Свертки сделать только начальные остатки. Необходимые для работы в следующем году данные вполне возможно перенести.

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

(28) Почему для очистки нельзя использовать инструменты администрирования, "Поиск и удаление дублей", "Удаление помеченных объектов", и все придет в порядок, относительный но все же

Делать свертку методом создания узла РИБ какая-то странная затея. Но как бы ОК. Мне непонятно, почему не работает вариант из (5)?
1. Делаем новую базу из оригинального cf
2. Зполняются все нужные элементы при старте.
3. Делаем базу подчиненной.
4. Докидываем регистрацией то чего не хватает в новой базе
5. ...
6. profit???
На каком шаге должна возникнуть проблема или дубли?

(33) на п.2

(34)Если можно подробнее, почему должны возникнуть дубли?

(35) Для начало маленькая ремарка - типовой обмен по риб заточен на синхронизацию по GUID. Мы не рассматриваем обмен по самописным правилам со своими полями поиска

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

У меня почему то подозрение что созданные элементы будут иметь ГУИД отличный от того что есть в старой базе. Ну вот почему то мне кажется, что создание идет не с конкретным гуидом, а будет генерироваться новый, уникальный.

Соответственно после синхронизации будут дубли

(35) в дополнение к словам Алексея

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

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

(38) Ну как сказать... я к примеру встречался с таким Как удалить "фантомные" записи в таблице итогов средствами 1С

Т.е. фантомные записи которые никак не удаляются. Так что проще cf + правила обмена

(38) давно бы уже попробовал не таблицы в СКЛ удалить, а убрать перед созданием образа лишние объекты из "состав объектов" плана обменов

Ты вообще в поторах конфигуратора на план обмена смотреть пробовал? Или тебе не западло в табличках сиквела ковырять, а в конфигураторе поснимать галочки религия запрещает?

(40)
1. делаю копию рабочей базы
2. в копии в плане обмена убираю из состава все не нужно
3. создаю начальный образ из копии
4. этот начальный образ отвязываю от центра
5. гружу в него cf от оригинала
6. привязываю к центру
Правильно?

(41) да.