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

Делать обработки встроенные в конфигурацию - не удобно.

Есть ли инструменты, чтобы делать внеш. обработки сразу в предприятии - и кодить и писать запросы? Формы, где рисовать не понятно.
Кто как делают код в расширениях ?

Решение простое - не создавать в расширении те объекты, которые можно выбрать в запросах)

(0) объекты относящиеся к базе данных создаем в основной конфигурации. Интерфейс и код в расширении.

И вовсе не из-за проблем внешних обработок

(1,2) Например я хочу в расширении добавить справочник "ОсобыеУсловия" и мне его естественно хочется ввести в ПВХ "ДополнительныеРеквизитыИСведения" в состав типов значения характеристик. Чтобы это изменить мне нужно не только ПВХ захватить, но и все объекты, входящие в составной тип. Разве нет?
Или при использовании расширений Дополнительные реквизиты не использовать?

(3) прошу перечитать (1,2) :)

(4) Вы отрицаете последние достижения компании 1С где можно реквизиты добавлять в расширении?

(5) без фанатизма, йуноша. Есил это мелкие реквизиты, то можно. А если что-то серьезное, только в основную конфу.

(6) Геня, ты что своего собрата по наездам на 1С не почувствовал? Точно стареешь...

(0) ИР же.

(0) > не видно объекты из расширения в запросах

Фирма 1С повышает ваш уровень развития, заставляя отказываться от конструктора запросов. Вы должны быть благодарны, а не страдать, что вам слишком сложно.

(6) Как это? У нас все клиенты хотят полбазы переписать не нарушая ни одного замка. И все уже знают про расширения.
(9) Точно, в девятке все запросы будете писать из командной строки. А потом и ее накроют. Покупайте маникюрные ножницы в перфокартах дырки резать.

(6) Без фанатизма у нас голодный останешься, а с фанатизмом - битым.

(10) клиентам деньги девать некуда?

(0) Делай запросы в режиме предприятия, отлаживай, а потом вставляй текст в код расширения.

(8)Поддерживаю.. ИР и никаких проблем.

(10) > в девятке
Да ты же первый плеваться будешь, когда 1С лямбды в язык впилят. Потому как устареешь и ничего не поймешь.

(15) Все будет хорошо... Надо только помучаться.

(0) Как вариант, консоль запросов.

(10) >> У нас все клиенты хотят полбазы переписать не нарушая ни одного замка. И все уже знают про расширения.

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

(18) У нас компании есть кто за "восстановление" базы платят чтобы все рукотворчество( зачеркнуто) рукожепство под замки вернули...

(19) >> компании есть кто за "восстановление" базы платят.

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

Идиоты обречены платить.
И ни какие технологии тут ничего не изменят. Они лишь будут давать этим лохам очередную иллюзию, что в это раз всё будет по-другому. А ничего по-другому не будет. Крайне мало кто умеет правильно пользоваться предоставляемыми возможностями.
Если разработчик не сумел допилить корректно прикладное решение под требования заказчика без расширений, то никакие расширения ему не помогут. Он и расширения наляпает так, что они будут косячить и создавать проблемы при обновлениях. Просто узкие места и проблемы сместятся с одних мест на другие.

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

(18) В этом психозе виновата сама фирма 1С. От них же шли рекомендации вести доработки преимущественно на расширениях.

(0)
1. Если у тебя расширение зачем тебе внешние обработки?
2. Запросы конструктором через консоль в режиме предприятия делай

(20) Ну ты загнул. Это скорее вендор не смог позаботиться чтобы разработчику удобно и весело было добавлять скокхошь расширений.

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

(22) >> От них же шли рекомендации вести доработки преимущественно на расширениях.

И где такие рекомендации были?
Я что-то пропустил?

Про рекомендации переноса внешних отчетов и обработок в расширения в конфигурациях с БСП (начиная с версии 2.5 и старше) слышал.
Но всем пофиг. Большинство так и продолжают клепать отчеты, обработки и печатные формы через справочник внешних обработок.

(24) >>  вендор не смог позаботиться чтобы разработчику удобно и весело было добавлять скокхошь расширений.

Вендор конечно инструментарий по расширениям явно не доработал и сильно ограничил. С этим трудно не согласиться.
Но проблема не только в этом.

Ты явно не понял смысл моих постов.

(26) "Большинство так и продолжают клепать отчеты, обработки и печатные формы через справочник внешних обработок." и правильно делают.
когда при каждом неудачном чихе обновления у тебя расширение отваливается- ты поневоле начинаешь думать: "а оно мне надо"?

(28) лучше явный отвал расширения чем неявный глюк внешней обработки

(9) если отбросить весь негатив, то именно благодаря этой фигне я смог писать запросы без конструктора. ( лень было в консоль лезть)  так что да. благодарен. вопрос, нужно ли бы мне было это умение, не будь расширений..

(29) не сталкивался.

(29) ну и соответственно явный глюк внешней обработки лучше чем неявный отвал расширения.

(28) >> когда при каждом неудачном чихе обновления у тебя расширение отваливается- ты поневоле начинаешь думать: "а оно мне надо"?

Это был довод в пользу расширений?
Странный ты выбрал способ доказать пользу расширений.

Вообще какая разница - отвалилось после обновление расширение или внешняя обработка/отчет? Принципиальной роли это не играет.

(33) это был довод в пользу обработок. как вы могли подумать обратное- мне непонятно. читайте внимательнее. там ещё строчка выше есть

(33) отвал обработки даже не заметят пока не попробуют ее запустить
отвал расширения сразу виден и можно сделать откат (вернуться к бэкапу) и допилить заранее расширение и только потом обновляться

(35)+ расширения это концепция авто тестов при каждом обновлении
если сделаете такие же авто тесты для внешних обработок то будет одинаково да

только расширения могут больше чем обработки а зачем плодить сущности?

(35) "отвал обработки "
что это? поясните нубу. не сталкивался.
или имеется ввиду, что код обработки натыкается на ошибку ввиду новых реалий конфигуратора после обновления?

(34) >> как вы могли подумать обратное...

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

К слову. Внешние отчеты, обработки и печатные формы - одна из тех сфер, где правильнее использовать именно расширения. Расширения прям идеально для такого применения подходят. И хорошая поддержка со стороны стандартных библиотек.

(37) угу
т.е. обработка после обновления не работает
и выяснится это в последний момент когда она понадобится, когда обновлятор уже ушел

(37) > имеется ввиду, что код обработки натыкается на ошибку ввиду новых реалий конфигуратора после обновления?

Да.
Причем "натыкается на ошибку" - это ещё хороший сценарий. Ошибка сразу проявляется, её легко найти и исправить.
Сложнее, когда поставщик изменил логику какой-то процедуры или функции, которую использует наша обработка. Например написал новую аналогичную функцию, а старую оставил только для совместимости.
Ошибки не будет. Но код будет работать неверно. Логическая бомба замедленного действия. Аналогичные проблемы могут быть конечно и при допиливании конфигурации прямо внутри, но там значительно выше шансы увидеть проблему при сравнении/объединении в ходе подготовки обновления.

(0) >>>> Главная проблема в том, что когда делаешь внеш. обработку не видно объекты из расширения в запросах.

Все просто, обработка из расширения, то значит расширение должно содержать практически все те объекты метаданных, что вы используете в обработке :)

+(0) >>> Кто как делают код в расширениях ?

Молча, скрепя зубами, и понимая, что может и что нужно для расширения, что бы все работало, как надо :)

(39) Все правильно, обновили конфу, потрудитесь переписать своё расширение под конфу, а вернее тот блок, который взаимно использует код и объекты из конфигурации :)

+ Хотите автономности в расширении?
1. Не пользуйтесь кодом из основной конфигурации
2. Старайтесь писать код универсально, а лучше так, что бы изменение конфигурации, хоть часть расширения работало :)

Моветон "Как отследить изменения в расширении?" (оно пухнет, а я один и не успеваю)

Все просто, я к примеру делаю "Зарубки" в коде, тип "Чек поинта"

//Пример

&НаКлиенте
&Вместо("НовыйДоговор")
Процедура СОГ_НовыйДоговор(Команда)
    
    //+
    СОГ_ДопФункции.ПроверитьВерсиюИсполняемогоКода("3.0.95.27"); //пропустил... маленький приоритет
    //-
    
КонецПроцедуры

//СОГ_ДопФункции

Функция ПроверитьВерсиюИсполняемогоКода(пРазрешеноРаботатьВерсии, Отказ=Ложь) Экспорт
    
    //Контроль версии 1С
    //пРазрешеноРаботатьВерсии = "3.0.70.25";
    Если Метаданные.Версия <> пРазрешеноРаботатьВерсии Тогда
        ТекстСообщения = "Сменилась версия 1С с '%1' на '%2', необходимо проверить функционал модуля! (сообщите программисту, он должен был проверить)";
        ТекстСообщения = СтрШаблон(ТекстСообщения,пРазрешеноРаботатьВерсии,Метаданные.Версия);
        ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения,,,, Отказ);
    КонецЕсли;

    Возврат Отказ;
КонецФункции

+ А дальше просто сверяем, ищем и смотрим, то что поменяло 1С :)

(44) "1. Не пользуйтесь кодом из основной конфигурации"
щас бы общие модули покопипастить ...
а потом поддерживать расширение вместо конфы..профит??!

(47) У меня уже 150 изменений, когда их 20, ваша речь логична.
А когда уже за сотню, и времени на обновления доходит до нескольких суток.

...Что сказать, кто не окунулся, всегда теориями машет...

(48) я прям щас сижу в этой теории.
и сравниваю код модуля из расширения, с кодом основной конфигурации.
песня..

(49) Смотри в (45), сравнивать придется только то ,что меняло 1С в своей поставке :)

(48) >> кто не окунулся, всегда теориями машет.

Это точно.

(48) возможно, вы поддерживаете своё расширение в одну каску, и тогда да, всё круто и логично. но не завидую тому, кто придёт после вас.
а я сейчас окунаюсь в модуль расширения, который по разным задачам переписывался 50 раз разными программистами.
лучше бы они свои условия пилили бесконечно после директивы &Вместо , чем бесконечно пилить свой модуль, где уже непонятно, кто прав...

+(50) но тут только будут проблемы с коллегами, вот мне трудно коллеге объяснить, что его комментарии в расширении не особо нужны, и желательно комментировать только там, где ты менял, а не комментировать то, что  является еще кодом от 1С :)

(52) Если в конторе приходящие, это вешалка :)

(27) Я понял смысл, но у нас это успешно продается и кормит народ.
"Народу нравится, дядя Вова" (с) КинДзаДза.
Почему во всем виноваты дураки? Не логичнее полагать что во всем виноваты умные?
А если вы такие умные почему у вас такое расширение?
Вот. Я просто аргументы не принимаю, с моей колокольни так слышно.

(30) Обычно такое осваивают увидев ЗУП или расчет себестоимости одним бесконечно раскусоченым запросом...

(56) не трогал зуп никогда. и не планирую. у нас с ним взаимная нелюбофф. не надо тапками. сам знаю..

(53) >> мне трудно коллеге объяснить, что его комментарии в расширении не особо нужны, и желательно комментировать только там, где ты менял, а не комментировать то, что  является еще кодом от 1С.

Спорное утверждение. Это конечно личное дело каждого разработчика.
Но я сторонник утверждения, что комментариев много не бывает. И лучше, когда они есть и пусть даже избыточны, чем когда их нет вовсе.
И комментировать код от 1С тоже очень часто бывает полезным. Когда потратишь полдня на разбор какой-нибудь методики, выяснишь наконец-то почему сделано именно так и что конкретно хотели авторы кода, а куда полученные знания записать, чтобы не тратить потом повторно кучу времени на разбор того же самого? Тем более, что бывает достаточно именно пару строчек комментариев прописать, чтобы всё стало понятным. Чем писать куда-то себе в базу знаний целую статью.

(58) Увы, только не для расширения :)

+ Краткость сестра таланта.

+(58) Т.е. получается при подмене функций, для человека, который накатывает обновления, нужно видеть только то что добавлял "программист организации".
Сверка кода осуществляется через Нотепад++  (плагин - Compare)... - Удобная штука.

В итоге всегда видно, что было от типового и что дописал программист. Ну а дальше дело техники, сопоставить выполняемый код :)

+ Надеюсь 1С когда-нибудь допишет, функции же так-то видны, которые перехватываются :)