В общем, делаю небольшое расширение, полностью отдельное от основной конфигурации.
Простенькие документы по учету талонов ГСМ, свой регистр для хранения. Передал нужные справочники в расширение, документ всё делает, движения идут.
Хочу добавить "типовую" кнопку "Дт/кт", чтобы можно было глянуть движения документа в привычной форме.
Команду "Показать движения" сделал свою, так как если передать расширением - там не смог поменять реквизит "тип параметра".
дальше передаю в расширение обработку "Корректировка движений" - и там вот ругается на то, что ссылка моего документа не вписывается в переменной "ДокументСсылка" оказывается пустота.
Я что-то сделал не так?

В частности там 1С хочет получить метаданные документа, чтобы заполнить структуру формы. И тут засада небольшая...

В общем, так как мои документы не работают с типовыми регистрами - просто скопировал в расширение эту обработку и там в типе параметра реквизита "ДокументСсылка" поставил интересующие меня документы.

(2) и зачем все эти танцы с бубном? В конфигурацию не мог свои объекты с прификсом K1RSAN добавить?

(3) и нах они там нужны? чтоб база тормозила при каждом очередном накатывании обновления типовой?

(3) Первое - расширение планируется паре клиентов сделать с разными конфигурациями (отраслевыми) на базе бухгалтерии. То ли делать 2 раза доработку, то ли сделать расширение, а потом просто проверить, как работает. А там может его отладить, прикрутить чего и тиражировать среди клиентов, как какой-нибудь популярный внешний отчет по определенной ставке.
Второе - ИМХО делать такие доработки, которые не касаются типового функционала по максимуму - лучше в расширении.

(5)+ ну и надо же осваивать расширения. Стильно-модно-молодёжно.

(6) ты хочешь хранить данные в расширении? по моему не комильфо

(4) чем же тебе помешают так сильно несколько не связанных с типовой объектов?

(7) Кстати да... Этот момент упустил.

(9) ничего ты не упустил

Впрочем... у вас же своя секта "нелюбителей", так что не буду вам мешать.

Тиражирование - одна из немногих причин для совершения подобных извращений.
Но если бы речь шла о разовой доработке, то соглашусь с (3) - делать подобное через расширение - дикий маразм.

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

(2) >> скопировал в расширение эту обработку и там в типе параметра реквизита "ДокументСсылка" поставил интересующие меня документы.

А остальные документы в этой связи в расширение не прилетели?

Лично я сделал бы отдельную поставку со своими объектами (документами, справочниками, перечислениями и пр.).
И отдельно - расширение для доработки типовых объектов основной конфигурации и интеграции своих объектов в интерфейс. Главным образом форм, общих команд (типа [Дт/Кт]) и обработок.

Можно пойти по пути добавления в забалансовых счетов. Доступно и всерьез.

(12) Нет, не прилетели
(11) Вот и думаю теперь... Доработка максимально оторвана от конфигурации, для неё важны только базовые справочники, которые используются в документах (типа номенклатура и контрагент), ставить если и будем куда-то, то только в бухгалтерии или их отраслевые

(10) что за секта?

(11) Тираж - громко сказано, просто есть несколько клиентов, которым может быть интересна подобная доработка. А чтобы не париться с тем, чтобы в их базы добавлять объекты отдельно - и думал воспользоваться расширением. Но если большой риск - то проще по-старинке

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

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

(17) >> Но если большой риск - то проще по-старинке.

Величину риска можешь оценить только ты сам.
Но о возможных последствиях лучше подумать заранее. Чтобы потом не завязнуть в бесконечных доработках своего расширения под каждое обновление для каждой отдельной конфы.

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

(18) Я сам раньше их почти не использовал, только когда "по наследству" доставалась база с расширением - в ней же небольшие правки делаю.
А тут просто подумал, что неплохой вариант "пощупать" возможности расширения.
Вообще, по вашему мнению, где лучше использовать расширения?

(20) >> возможность потери данных, которые некоторые пытаются хранить в расширениях.

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

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

(22) у основной конфигурации режим совместимости 8.3.14. Вроде же от него зависит, какие возможности расширений доступны?

(21) Расширения идеальны для.
1. К конфигурациям с БСП вместо устаревших внешних отчетов, обработок и печатных форм. В БСП под это дело допилена целая подсистема.
2. Временные патчи по аналогии с теми, которые публикует 1С к своим типовым конфигурациям. После выхода обновления с исправлением ошибок такие патчи удаляются.
3. Какие-то доработки "сбоку", которые не затрагивают основной функционал и бизнес-логику, и как следствие имеют мало шансов "сломаться" при очередном обновлении от поставщика. При этом следует крайне аккуратно использовать функционал стандартных библиотек (БСП, БПО, БЭД, БРО и т.п.) т.к. они постоянно обновляются и иногда даже сильнее, чем основная конфигурация поставщика.

Лучше избегать расширений.
1. При вмешательстве в какие-либо ключевые механизмы бизнес-логики. Например, при доработке НДС в БП или расчета з/п в ЗУП. 1С часто меняет логику работы таких механизмов. А без инструмента трёхстороннего сравнения (старая конфа поставщика / новая конфа поставщика / доработки) понять будет ли корректно работать расширение после обновления не всегда возможно. Особенно, если расширение писал не ты сам или писал сам, но давно, и оно не документировано.
2. Расширение данных. Добавлять свои собственные объекты (документы, справочники, регистры и т.д.) или собственные реквизиты к типовым объектам. В таком случае лучше данные расширять (добавлять объекты и реквииты) в самой конфе, а интеграцию в интерфейс основной конфы делать через расширения (например, выводить добавленные реквизиты на формы).

Невозможно отказаться от расширений.
1. Конфа в облаке в режиме сервиса (фреш). Изменение конфигурации невозможно, кроме как при помощи расширений.
2. Клиника в башке заказчика, который запрещает включать возможность изменения.

Это конечно не все случаи. Но основные.

(24) Речь в (22) не о возможностях конкретной версии. Хотя я точно не помню - с какой версии появилась возможность расширять данные.
Речь о косяках самой платформы. Когда в случае отваливания расширения (например, из-за невозможности применения расширения после обновления из-за какой-нибудь ошибки) пропадали те данные (документы, справочники, реквизиты и т.п.), которые расширялись при помощи этого расширения.
На сколько знаю, в последних релизах всех веток (включая 8.3.14) это поправили.

(25) Спасибо

(26) ну вот видишь, поправили этот глюк очень давно.

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

Но благодаря усилиям некоторых мистян, тема безопасности работы в расширениях превратилась в мини-срач...
ВиндаМастДай и Красноглазики ... ваксеры/анти-ваксеры ... осталось еще и на расширения нечто похоже придумать.

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

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

(28) Я вовсе не против расширений. Расширения - классная и полезная штука.
Я против бездумного их вкорячивания всегда и везде. Где надо и где не надо. Как, например, сделал автор ветки. Как раз тот случай, когда часть доработки надо делать в конфигурации, а часть - в расширении.
А уж писать расширения исключительно ради того, чтобы не включать возможность изменения конфигурации, - вообще дичь.

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

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

что мешает создать в расширении новую общую команду с синонимом "Движения документа" с нужным типом команды и кодом вызова как в оригинале..

(31) эх... вот если бы "классический подход" был в реальности классическим.
Многие "классики" не представляют себе ситуации, когда на продуктиве принципиально не следует оставлять в наличии конфу поставщика.

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

(32) Так и сделал для пробы

(29) >> трёхстороннее сравнение никак не гарантирует корректность работы (вообще никак).

Конечно не гарантирует. Но даёт хоть какие-то шансы.
Зато отсутствие инструментов сравнения гарантирует, что корректность работы своего расширения вы не проверите (вообще никак).

Называется "почувствуйте разницу".

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

(31) Ну в моём случае не вижу смысла делать "часть тут, часть там". Делать чисто объекты (документы-регистры) в конфигурации, а формы - в расширении - а зачем? Всё равно все "пересечения" между доработкой и типовой конфигурацией - это использование типовых кнопок "Показать дт/кт" и печатных форм. Уж проще всё держать в конфе, если расширение "вредно", чем цирк устраивать с разделением объекта на кусочки.

(37) проще вообще ничего не делать, чем делать.

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

У тебя конфа заказчика какой версии?

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

(38) Бухгалтерия отраслевка, "соответствует" Бухгалтерии для Казахстана актуальной. Режим совместимости 8.3.14. Работаем на платформе 8.3.17.1851, некоторые на 8.3.15.1958.
3 документа, 1 регистр накопления, "пересечение" с типовым функционалом только в плане использования общих модулей, подписок на событие и команд типа "показать движения".

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

>> Вы обещали, что расширения решат вопрос с обновлениями раз и навсегда) и т.п.
Собственно, вот она, Ваша ключевая проблема.
Сначала обещаете, не разбираясь в вопросе (читай врёте), а потом всё валите на несовершенство мира / 1С / расширения

>> И обоснованные претензии от заказчиков...
Естественно, вот только это претензии не к расширениям, а к исполнителю / качеству его работ / его обещаниям

Задача ТС отлично подходит для расширений.

(40) Про претензии к исполнителю я как раз привёл не свой пример. У меня с этим давным-давно всё нормально.
И никто не спорит, что задача ТС подходит для расширения.

Ты что-то сам себе напридумывал про меня и теперь обвинениями начинаешь разбрасываться. Зачем? Нормально ж общались. ;)

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

Расширения несовершенны (никто не говорит, что плохи). Как и мир вокруг нас. Когда четко знаешь обо всех особенностях и ограничениях конкретного инструмента, становится проще жить. Вот и всё. Не больше, но и не меньше.

(41) Ну вот, опять, я процитировал ваши слова, а пишете, что придумал.
Сначала пишете, что "корректность работы своего расширения вы не проверите", а потом вдруг, что с чем-то там из инструментов тестирования знакомы.
Враньё-с.

(0) в расширении в форме обработки Корректировка движения у реквизита ДокументДвижения поставь тип "Произвольный"

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

Складывается впечатление, что ты не мнение моё хочешь узнать или своё мнение высказать, а непременно в чем-то уличить, подловить и обвинить, на каком-то вранье поймать. Зачем? Или это такая манера общения? Или где-то смайликов не хватает?
Какой смысл мне врать? Или ты реально считаешь, что существует секта противников расширения, а её представитель? Спешу тебя разочаровать. Секта если и есть, то я о ней ничего не знаю. И против расширений ничего не имею. А если и имею, то только против бездумного их применения.
У меня есть некий опыт и я им делюсь. Пользоваться этим опытом или нет - личное дело каждого. Мне от этого ни тепло ни холодно.
Работы по переписыванию кривых расширений, которые сейчас плодятся, как кролики, бездумно и в огромных количествах, видимо ещё долго будет предостаточно. Не смотря ни на моё ни на твоё мнение.

(43) какой настоящий 1сник не презирает авто тестирования

(44) Автотесты нужны на тиражных решениях и хороши на крупных и/или длинных внедрениях.
Если каждому клиенту на каждую доработку настраивать автотестирование, работать будет некогда. В тестописателя превратишься. )))

(44) он его перекладывает на конечного пользователя?