Обновление нетиповой конфигурации и расширение
По теме из базы знаний
- Технология обновления нетиповых конфигураций 1С:Предприятия 7.7
- Обновление нетиповой конфигурации с приведением к типовой и выносом всех доработок в расширение. Часть/Способ №1
- Обновление нетиповой конфигурации с приведением к типовой и выносом всех доработок в расширение. Часть/Способ №2
- Обновление нетиповой конфигурации ЗУП одним махом через 19 релизов + решение глюков обновлений (памятка)
- Использование внешних программных средств при обновлении конфигураций 1С
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Этот реквизит есть в табличной части основной конфигурации и он заимствован в расширении? И в основной конфигурации он удален? Я правильно понял?
Тогда его и в расширении нужно удалить. И все будет работать. Или я не прав?
у табличной части документа удаляется реквизит, используемый в расширении
Этот реквизит есть в табличной части основной конфигурации и он заимствован в расширении? И в основной конфигурации он удален? Я правильно понял?
Тогда его и в расширении нужно удалить. И все будет работать. Или я не прав?
(11) Я сливаюсь. Автору нужно другое, но ответ я не знаю. Могу выложить ответ Claude 3.7 Sonnet, если это чем-то поможет:
Заключение
Проблема с удалением реквизита табличной части при обновлении нетиповой конфигурации 1С требует внимательного анализа и планирования. Основное решение заключается в адаптации расширения к изменениям в основной конфигурации либо путем удаления заимствованного реквизита из расширения, либо созданием собственного реквизита с уникальным именем. Также важно следовать рекомендациям по корректному обновлению нетиповых конфигураций и тщательно тестировать все изменения перед применением в рабочей среде.
Проблема с удалением реквизита табличной части при обновлении нетиповой конфигурации 1С требует внимательного анализа и планирования. Основное решение заключается в адаптации расширения к изменениям в основной конфигурации либо путем удаления заимствованного реквизита из расширения, либо созданием собственного реквизита с уникальным именем. Также важно следовать рекомендациям по корректному обновлению нетиповых конфигураций и тщательно тестировать все изменения перед применением в рабочей среде.
(13) Там сказано, что при обновлении конфы удаляется реквизит используемый в расширении.
Используемый в расширении. Используемый.
При обновлении конфы. Нетиповой конфигурации. Не при обновлении расширения.
Подумай. Или спроси у старших.
Даже ИИ вопрос понял правильно. И даже ответ дал почти правильный.
Используемый в расширении. Используемый.
При обновлении конфы. Нетиповой конфигурации. Не при обновлении расширения.
Подумай. Или спроси у старших.
Даже ИИ вопрос понял правильно. И даже ответ дал почти правильный.
(15)
Отсюда вытекает, что и твое расширение должно быть переработано, чтобы а) или работать без этого реквизита б) или уметь работать с новой логикой основной конфигурации.
Других вариантов не существует.
Ручками, только ручками.
ИИ не поможет.
Небось уже во всем без нас разобрался.
А че тут разбираться? В основной конфигурации исчез реквизит. Значит он а) или больше не нужен б) или переработана логика его использования.
Отсюда вытекает, что и твое расширение должно быть переработано, чтобы а) или работать без этого реквизита б) или уметь работать с новой логикой основной конфигурации.
Других вариантов не существует.
Ручками, только ручками.
ИИ не поможет.
(16) То есть это был реквизит из конфигурации поставщика? Его в конфигурации поставщика удалили, и он удалился в основной конфигурации?
Если так, то это нормально. В "дважды измененные" попадают реквизиты которые входят в конфигурацию поставщика, но были изменены в основной конфигурации. Меня сбила с толку фраза
По традиции, сначала советуюсь с ИИ:
Анализ ситуации с удалением реквизита при обновлении конфигурации 1С
Да, ответ пользователя форума проясняет ситуацию. Давайте разберемся более детально:
Что произошло
Судя по всему, речь идет о реквизите, который:
Изначально существовал в конфигурации поставщика (типовой)
Был заимствован в расширении
При обновлении был удален из конфигурации поставщика
После обновления основной конфигурации этот реквизит исчез и в ней
Почему документ не попал в "дважды измененные"
"Дважды измененные" объекты — это те, которые были изменены как в вашей основной конфигурации (относительно предыдущей версии конфигурации поставщика), так и в новой версии конфигурации поставщика. То есть, для попадания в "дважды измененные" должны выполняться два условия:
Объект был изменен в вашей основной конфигурации (вы внесли какие-то доработки)
Тот же объект был изменен в новой версии конфигурации поставщика
В вашем случае, похоже, документ не был изменен в вашей основной конфигурации (вы не вносили в него доработки на уровне основной конфигурации), а использовали его "как есть" и только в расширении добавили к нему функциональность. Поэтому документ не попал в "дважды измененные" — с точки зрения механизма обновления, вы не меняли этот документ в основной конфигурации.
Почему реквизит удалился
Реквизит удалился, потому что:
Он был удален в конфигурации поставщика
Ваша основная конфигурация унаследовала это изменение при обновлении
Расширение, которое использовало этот реквизит, теперь не может его найти
Что с этим делать
Ответ пользователя форума абсолютно верен. У вас есть два пути:
Адаптировать расширение для работы без этого реквизита:
Если реквизит больше не нужен в логике работы конфигурации поставщика, вам нужно перестроить расширение так, чтобы оно тоже обходилось без него
Адаптировать расширение к новой логике:
Если в конфигурации поставщика реквизит был заменен чем-то другим или логика работы была изменена, вам нужно изучить эти изменения и соответствующим образом обновить расширение
Дополнительные варианты решения
Создать свой реквизит в расширении:
Если функциональность реквизита все еще необходима для вашего бизнес-процесса, вы можете создать собственный реквизит с тем же назначением в расширении
Это даст вам независимость от изменений в конфигурации поставщика
Проверить, не был ли реквизит переименован или перемещен:
Иногда при обновлении реквизиты не удаляются полностью, а переименовываются или перемещаются в другие структуры
Стоит проверить, не появился ли похожий реквизит с другим именем
Заключение
Эта ситуация — классический пример того, почему при использовании расширений рекомендуется:
По возможности создавать собственные объекты и реквизиты в расширении, а не полагаться на объекты основной конфигурации
Тщательно тестировать работу расширений после каждого обновления основной конфигурации
Иметь стратегию адаптации расширений к изменениям в основной конфигурации
К сожалению, в данном случае действительно требуется ручное вмешательство для адаптации расширения к изменениям в основной конфигурации, и автоматизированного решения этой проблемы не существует.
Если так, то это нормально. В "дважды измененные" попадают реквизиты которые входят в конфигурацию поставщика, но были изменены в основной конфигурации. Меня сбила с толку фраза
Документ не входит в "дважды измененные".
Я подумал, что это случай автора. Тогда, по идее, такой реквизит не должен удаляться?
По традиции, сначала советуюсь с ИИ:
Анализ ситуации с удалением реквизита при обновлении конфигурации 1С
Да, ответ пользователя форума проясняет ситуацию. Давайте разберемся более детально:
Что произошло
Судя по всему, речь идет о реквизите, который:
Изначально существовал в конфигурации поставщика (типовой)
Был заимствован в расширении
При обновлении был удален из конфигурации поставщика
После обновления основной конфигурации этот реквизит исчез и в ней
Почему документ не попал в "дважды измененные"
"Дважды измененные" объекты — это те, которые были изменены как в вашей основной конфигурации (относительно предыдущей версии конфигурации поставщика), так и в новой версии конфигурации поставщика. То есть, для попадания в "дважды измененные" должны выполняться два условия:
Объект был изменен в вашей основной конфигурации (вы внесли какие-то доработки)
Тот же объект был изменен в новой версии конфигурации поставщика
В вашем случае, похоже, документ не был изменен в вашей основной конфигурации (вы не вносили в него доработки на уровне основной конфигурации), а использовали его "как есть" и только в расширении добавили к нему функциональность. Поэтому документ не попал в "дважды измененные" — с точки зрения механизма обновления, вы не меняли этот документ в основной конфигурации.
Почему реквизит удалился
Реквизит удалился, потому что:
Он был удален в конфигурации поставщика
Ваша основная конфигурация унаследовала это изменение при обновлении
Расширение, которое использовало этот реквизит, теперь не может его найти
Что с этим делать
Ответ пользователя форума абсолютно верен. У вас есть два пути:
Адаптировать расширение для работы без этого реквизита:
Если реквизит больше не нужен в логике работы конфигурации поставщика, вам нужно перестроить расширение так, чтобы оно тоже обходилось без него
Адаптировать расширение к новой логике:
Если в конфигурации поставщика реквизит был заменен чем-то другим или логика работы была изменена, вам нужно изучить эти изменения и соответствующим образом обновить расширение
Дополнительные варианты решения
Создать свой реквизит в расширении:
Если функциональность реквизита все еще необходима для вашего бизнес-процесса, вы можете создать собственный реквизит с тем же назначением в расширении
Это даст вам независимость от изменений в конфигурации поставщика
Проверить, не был ли реквизит переименован или перемещен:
Иногда при обновлении реквизиты не удаляются полностью, а переименовываются или перемещаются в другие структуры
Стоит проверить, не появился ли похожий реквизит с другим именем
Заключение
Эта ситуация — классический пример того, почему при использовании расширений рекомендуется:
По возможности создавать собственные объекты и реквизиты в расширении, а не полагаться на объекты основной конфигурации
Тщательно тестировать работу расширений после каждого обновления основной конфигурации
Иметь стратегию адаптации расширений к изменениям в основной конфигурации
К сожалению, в данном случае действительно требуется ручное вмешательство для адаптации расширения к изменениям в основной конфигурации, и автоматизированного решения этой проблемы не существует.
(17)
UPD. С другой стороны - нам это нафиг неинтересно. Почему он исчез из основной конфигурации - вообще не наше дело. Исчез и исчез. Может поставщик удалил, может шаловливые ручки. Нас интересует только факт основной конфигурации - реквизит был да сплыл. А всё остальное не имеет значения.
То есть это был реквизит из конфигурации поставщика?
Конфигурация нетиповая, там вообще может не быть конфигурации поставщика. Опять же мы не знаем авторский способ "обновления" - через поддержку, через сравнение, через загрузку...
UPD. С другой стороны - нам это нафиг неинтересно. Почему он исчез из основной конфигурации - вообще не наше дело. Исчез и исчез. Может поставщик удалил, может шаловливые ручки. Нас интересует только факт основной конфигурации - реквизит был да сплыл. А всё остальное не имеет значения.
(20) Мне интересен такой момент. Автор с нами перестал общаться после третьего поста. Почему?
Мои предположения:
1.Во всем разобрался сам, дальше ему с нами общаться неинтересно.
2.Возможно, автор человек неуверенный, не захотел попасть под каток критики в свой адрес. На форуме автор 27 дней, если и в профессии столько же, то наверняка неправильно употребляет термины и не до конца понимает то, о чем говорит. Таких тут порвут как тузик грелку.
Мои предположения:
1.Во всем разобрался сам, дальше ему с нами общаться неинтересно.
2.Возможно, автор человек неуверенный, не захотел попасть под каток критики в свой адрес. На форуме автор 27 дней, если и в профессии столько же, то наверняка неправильно употребляет термины и не до конца понимает то, о чем говорит. Таких тут порвут как тузик грелку.
(24)
С чего вдруг обновление конфигурации должно знать о расширении и самостоятельно его как-то обновлять?
расширение тоже автоматически обновляется вместе с конфигурацией
Как это? Конфигурацию написала одна фирма, а расширение - левый разработчик. Они друг про друга ничего не знают.
С чего вдруг обновление конфигурации должно знать о расширении и самостоятельно его как-то обновлять?
(26) Да, теперь дошло, а по-другому никак. Есть у нас любители рассказывать сказки, что надо читать документацию, и тогда у тебя не будет вопросов. В этой документации черт ногу сломит. А самое главное, какую главу читать, на что обратить внимание? Не факт, что в документации фокус внимания на твоем вопросе сосредоточен. Возможно, там что-то где-то мельком сказано, и все.
(28)
А вот поддержу! Доколе? Совсем уже классику забыли:
В этой документации черт ногу сломит. А самое главное, какую главу читать, на что обратить внимание? Не факт, что в документации фокус внимания на твоем вопросе сосредоточен. Возможно, там что-то где-то мельком сказано, и все.
А вот поддержу! Доколе? Совсем уже классику забыли:
Дурака лелеют, дурака заботливо взращивают, дурака удобряют… Дурак стал нормой, еще немного — и дурак станет идеалом, и доктора философии заведут вокруг него восторженные хороводы. А форумы водят хороводы уже сейчас. Ах, какой ты у нас славный, дурак! Ах, какой ты бодрый и здоровый, дурак! Ах, какой ты оптимистический, дурак, и какой ты, дурак, умный, какое у тебя тонкое чувство юмора, и как ты ловко решаешь кроссворды!.. Ты, главное, только не волнуйся, дурак, все так хорошо, все так отлично, и наука к твоим услугам, дурак, и литература, чтобы тебе было весело, дурак, и ни о чем не надо думать… А всяких там вредно влияющих хулиганов и скептиков мы с тобой, дурак, разнесем (с тобой, да не разнести!).
(25)
Легко. Если фирма 1С захочет чтобы было так, то будет так. Спорить никто не будет. Нелогично, неправильно? Что ж, бывает и так.
(25)
Это очевидно для тех кто уже 10 лет пользуется расширениями и столько же сидит на форуме, для всех остальных это неочевидно. Более того, не может и не должно быть очевидно.
Как это?
Легко. Если фирма 1С захочет чтобы было так, то будет так. Спорить никто не будет. Нелогично, неправильно? Что ж, бывает и так.
(25)
Конфигурацию написала одна фирма, а расширение - левый разработчик. Они друг про друга ничего не знают.
Это очевидно для тех кто уже 10 лет пользуется расширениями и столько же сидит на форуме, для всех остальных это неочевидно. Более того, не может и не должно быть очевидно.
(30) Ну хорошо. Тогда объясни, пож-та, такой момент. В модуле команды могут быть использованы следующие директивы компиляции:
&НаКлиенте – процедура/функция исполняется в управляемом клиенте;
&НаСервере – процедура/функция исполняется на сервере;
&НаКлиентеНаСервере – процедура/функция может исполняться и в управляемом клиенте, и на сервере.
Директива &НаСервере намекает на то, что на сервере будет доступен некий контекст. Я бы так подумал с точки зрения логики. По крайней мере, в модуле формы это работает так: есть директива &НаСервере и &НаСервереБезКонтекста. А тут какой контекст? В модуле формы можно обратиться к контексту напрямую, либо написать ЭтотОбъект и через точку нужный реквизит. А тут какие реквизиты в модуле команды?
Было бы логично использовать директиву &НаСервереБезКонтекста с точки зрения логики.
&НаКлиенте – процедура/функция исполняется в управляемом клиенте;
&НаСервере – процедура/функция исполняется на сервере;
&НаКлиентеНаСервере – процедура/функция может исполняться и в управляемом клиенте, и на сервере.
Директива &НаСервере намекает на то, что на сервере будет доступен некий контекст. Я бы так подумал с точки зрения логики. По крайней мере, в модуле формы это работает так: есть директива &НаСервере и &НаСервереБезКонтекста. А тут какой контекст? В модуле формы можно обратиться к контексту напрямую, либо написать ЭтотОбъект и через точку нужный реквизит. А тут какие реквизиты в модуле команды?
Было бы логично использовать директиву &НаСервереБезКонтекста с точки зрения логики.
(31) Если контекста нет, какой контекст ты собираешься ограничить директивой &НаСервереБезКонтекста?
Видимо, разработчики платформы подумали, что раз контекста нет, то и заставлять писать эту фразу каждый раз не имеет смысла. Просто упростили жизнь разработчикам конфигураций.
Вот и вся логика.
Видимо, разработчики платформы подумали, что раз контекста нет, то и заставлять писать эту фразу каждый раз не имеет смысла. Просто упростили жизнь разработчикам конфигураций.
Вот и вся логика.
(32) Это подтверждает мою мысль, что на логику опереться не получится. А у меня другая логика, что будем делать? Я бы разрешил обе директивы, и &НаСервере, и &НаСервереБезКонтекста.
Я бы не назвал директиву &НаСервереБезКонтекста ограничением. Я бы назвал это скорее разрешением. Разрешением серверу отдохнуть, не гонять данные с клиента на сервер и обратно.
Я бы не назвал директиву &НаСервереБезКонтекста ограничением. Я бы назвал это скорее разрешением. Разрешением серверу отдохнуть, не гонять данные с клиента на сервер и обратно.
(34) Ну запили свою платформу со своей логикой.
А раз пользуешься платформой от 1С, то учитывай документацию и логику разработчиков платформы. Это единственно, что важно.
Платформа работает именно так.
А отдельные мнения, твое, мое, других пользователей по этому вопросу никого не интересуют, т.к. ни на что не влияют, и ничего изменить не могут.
Это как в Вкусно и точка слоган - "жри че дали".
А раз пользуешься платформой от 1С, то учитывай документацию и логику разработчиков платформы. Это единственно, что важно.
Платформа работает именно так.
А отдельные мнения, твое, мое, других пользователей по этому вопросу никого не интересуют, т.к. ни на что не влияют, и ничего изменить не могут.
Это как в Вкусно и точка слоган - "жри че дали".
(37)
Это будут делать роботы, такие как
Он находит и обобщает информацию с сайта ИТС. Подискутировать с ним не получается, но это все равно лучше чем раньше, когда ты должен был сам заходить по ссылкам, читать и обобщать информацию. Можно и самому провалиться в ссылку и почитать документацию. Если ссылок 3, то это уже вполне выполнимо.
Кто это будет делать другой за тебя?
Это будут делать роботы, такие как
Он находит и обобщает информацию с сайта ИТС. Подискутировать с ним не получается, но это все равно лучше чем раньше, когда ты должен был сам заходить по ссылкам, читать и обобщать информацию. Можно и самому провалиться в ссылку и почитать документацию. Если ссылок 3, то это уже вполне выполнимо.
(40)
Если ответ сформулировал бот консультант ИТС, то можно написать претензию
Ну, то есть, получается, чтобы понять, что информация неверна, тебе надо уже знать правильный ответ. А зачем тогда вообще бота спрашивать? Или формулировка претензии будет "я вообще ничего не понял, что ваш бот мне говорит"?
(42) Для того чтобы узнать, что ответ неправильный, нужно попробовать применить ответ бота на практике. Если он скажет, что можно использовать директиву &НаСервереБезКонтекста в модуле команды (он такого не говорил, но предположим гипотетически), то я попробую использовать директиву &НаСервереБезКонтекста в модуле команды, получу ошибку и напишу на бота жалобу в отдел ИТС.
UPD
С Claude Sonnet такой фокус не пройдет. Жаловаться непонятно куда. Клод мне настоятельно советовал использовать директиву &НаСервереБезКонтекста в модуле приложения.
UPD
С Claude Sonnet такой фокус не пройдет. Жаловаться непонятно куда. Клод мне настоятельно советовал использовать директиву &НаСервереБезКонтекста в модуле приложения.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот