Добрый день!

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

Может наоборот перенести все в расширение ?

Гм. "Умельцы" - это оскорбление или восхищение?

Через пару лет я прям вижу новую ветку, Одни умельцы внесли все доработки в основную конфигурацию, как эти доработки перенести в расширение?

Может, как и они, почитать про расширения?

если sql версия,то можно схитрить
на файловой сложнее,но таблица с данными,она и в расширении таблица
выгрузил загрузил.

(2) Создавать реквизиты в расширении - это однозначно неправильно.
(4) Может если вы подскажете направление поиска, то читать придётся меньше?

Создать реквизит в конфигурации, перенести значения с расширения в конфигурацию, удалить реквизит с расширения, переименовать реквизит в конфигурации

(7) Натянуть формы заново, не думаю что эти умельцы нагрузились изменять их программно

Это самый прямой и тупой метод, большее я не практиковал

(3) Уже выходили такие темы, когда 1с выпустит инструмент по сохранению данных расширения, тогда это будет целесообразно

(7, 9) Вот я собственно в (0) спросил - может быть можно как-то побыстрее и попроще? Там навскидку таких документов штук 40, это очень много работы всё вручную переносить

(11) чем не устраивает реквизиты в расширении? угроза потерять данные? или что-то еще?

(12) И ещё невозможность писать запросы т.к. то в одной то в другой конфе нет нужных метаданных. Можно, конечно, сделать (1), но это таким затейником нужно быть )

(13) вы от том что в расширении конструктор запроса не работает? ну так пользуйтесь конструктором во внешней обработке, все так делают, есть такой нюанс

(11) Навскидку приходит на ум ещё один способ, подобный (7 и 9): создаём копию базы в которой реквизиты не в расширении, переносим данные, и переименовывать ничего не надо. Но есть минус в том, что надо останавливать работу пользователей, пока данные не перенесены.

(14) И ради чего такие извращение? Тупо потому что это "модно" и "молодёжно"? Преимуществ никаких. От слова "совсем". А геморроя - вагон и маленькая тележка.
Авто абсолютно прав. Расширения не для таких целей создавались.

(0) Оставить все как есть.

+17 Заняться более важными задачами.

Создавать реквизиты в расширении - это однозначно неправильно

Это ты чем аргументируешь?

(0) Никаких волшебных методов нет.
Только стандартный подход, аналогичный тому, как бы ты это делал в самой конфигурации.
1. У существующего в расширении реквизита ставим префикс имени "Удалить".
2. Добавляем реквизит в основной конфигурации.
3. Обработкой переносим данные из реквизита "Удалить" во вновь созданный.
4. Удаляем реквизит с префиксом "Удалить".

(19) А зачем? Хоть один довод существует в пользу того, чтобы создавать реквизит в расширении. Кроме геморроя с конструктором запросов?

проблема с конструктором запросов стоит на 1 или 2 месте всех проблем расширения, но только с конца

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

Все носятся с этими расширениями как с писаной торбой. И начинают использовать их там где надо и где не надо.
И надув щёки возмущаются - какая 1С плохая - криво расширения сделала.

Есть один существенный минус с реквизитами. Если добавлять реквизит на форму из расширения, то в форму расширения потянется абсолютно всё: и таб.части и все реквизиты...
Поэтому, добавляю реквизиты на форму в расширение программным образом.

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

(25) Если она не на подддержке...

(24) Этот минус победили в 8.3.14 (если не ошибаюсь).
Сейчас данных тянется значительно меньше в расширение.

А если типовая, то можно попробовать обойтись расширением.

(26) Как поддержка связана с возможностью изменения?
Кто запрещает включить возможность изменения не снимая с поддержки? Религия?

(27) Не заметил. На 8.3.15 абсолютно всё тянет.

(28) А если типовая, то проще и правильнее включить возможность изменения с сохранением поддержки и не ипать самому себе мозг.

(30) Режим совместимости может оставлен 8.3.13?

(25) да, я тоже не сторонник расширять _данные_, да и сыровато оно еще
расширяю все кроме данных, реквизиты предпочитаю создавать в основной конфе

(29) Типовой зуп вот совсем никак не хочется снимать с замка.

(32) Нет. Режим совместимости 8.3.14

(0) Мы решили эту проблему пересозданием объектов в расширяемой конфигурации.
1С в обозримом будущем даст возможность сопоставлять объекты расширяемой и расширения по гуид, чтобы можно было безболезненно выносить их обратно в расширение, когда они победят технические органичения платформы.
Сейчас для себя в стандарте разработки расширение данных запретили на горизонте 2-3 лет.

(34) наоборот. В типовом ЗУП даже с этим проще. Снимайте смело.

(37) Пока баловства ради делаю в расширении, задача терпит. Но есть вероятность, что буду делать всё в конфе.
Есть самоубийцы, которые добавляли в расширение документ и к нему делали движения по регистрам ?

(38) в этом вообще нет никакого смысла. Тут по-любому надо в основной конфигурации делать. С расширением никаких плюсов не получишь, только один бесконечный геморрой на несколько лет.

(39) Ну что же, печаль.

(38) Самоубийцы есть. Посмотрите отраслевые решения ERP. Внедрений нет.
Когда я поднимал тему месяц назад, чтобы собрать всю боль на бою по расширениям, не нашел ни одного крупного внедрения на данном механизме.

(38) Есть. Например Битрикс. Модуль обмена УТ-Битрикс24 нарисован полностью расширением. В нем справочники, регистры. Документов нет, но думаю если бы для обмена они были нужны, они бы это нарисовали.

(41,42) Спасибо за информацию.

Можно делать полностью на Расширении. Я так делаю. Но! Это не гибрид, не смешивание реквизитов в ТЧ документа из основной с реквизитами этого же документа в расширении - нет.

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

Ну и для основной дополнения отчетных форм, печатных форм, измененные процедуры пересчета сумм иногда.

(42) Массовый тиражный продукт - это один из тех немногих случаев, когда применение расширения имеет смысл.
Если вы хотите разработать некую вундервафлю, которую планируете внедрять/продавать многократно, то безусловно имеет смысл заморачиваться с расширением.
Расширение передал заказчику. Тот его может даже самостоятельно установить без участия программиста.

Разовая индивидуальная разработка в расширении смысла не имеет.
Пока что расширения - это патчи (временные заплаты, которые будут удалены по мере исправления багов в основной конфе) и дополнительные отчеты и обработки (то, что раньше, до БСП 2.5, называлось внешние отчеты и обработки). Для остального использование расширения следует рассматривать индивидуально и в большинстве случаев бессмысленно.