<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Интересно получается. Заимствуются не ссылки, как я надеялся.
Когда меняешь непосредственно типовую, можешь просто сравнить и объединить, отловив дважды измененные. Да еще можно собрать все в собственную подсистему для целей фильтрации.
Все за один шаг. Можно за несколько подходов.
А когда расширяешь надо делать буферную конфигурацию, которую и сравнивать с основной рабочей.
А потом править расширение на буферной?
Или сравнивать основную с файлом, выгруженным из расширения с тем, чтобы вернуться к буферной, обновить или создать ее вновь с новыми и измененными и переделать расширение.
А в чем смысл?
ERP примерно раз в месяц третью цифру меняет, видимо метаданные раз в месяц и меняются.
Или пронесло или снова здравствуйте. Садись сравнивать или запрети покупателям обновлятся, пока не сделаешь расширение..
Расширение — это косяк или ценное качество? Даже и не понятно. Ну кроме, того что эти наши дурацкие доработки для 1с — второстепенная проблема, можно всегда отстрелить расширение и ехать дальше.
А какая версия платформы у вас используется? в последних 8.3.10 нет прогресса с расширениями?
(1)
судя по всему, да, что бы было совместимо разными конфигурациями, поэтому наименования
Расширение править можно и не на буферной, но заимствовать формы, скорее всего, придется на буферной.
разработчик платформы предлагает расширение как альтернативу изменениям типовой конфигурации, что бы можно было оставаться в чистой типовой на автоматических обновлениях и при этом иметь адаптированный под конкретный бизнес фукционал. Просто пока не все продумано здесь до конца.
К счастью, расширение при изменении ключевых метаданных основной конфигурации перестает работать на этапе запуска 1С:Предприятия, поэтому отловить ошибки совместимости можно руками стажеров (либо даже написать скрипт (пока не разработал)) прямо в день входа нового релиза.
Если затягивать в расширение минимум метаданных, то оно может достаточно долго продержаться без изменений.
1С постоянно апдейтит функционал расширений, например, на версии 8.3.11 можно будет добавлять свои данные (например, справочники, реквизиты в существующие справочники)
(0),
В ЗУП3.1 в расширяемых формах документов множество лишних элементов удалено (оставлено только то, что задействовано в доработках) — полет нормальный. Может от версии платформы зависит?
(3) если к удаленным элементам формы (не данным объекта, а именно элементам формы) нет обращения в коде (с учетом того, что расширение может отменять часть кода расширяемой формы), то работоспособность не будет утрачена, однако удаленного в расширении элемента формы на результирующей форме не будет (только что перепроверил, при удалении элемента с формы в расширении он удаляется на результирующей форме)
(2)
Кто такой этот стажер? Это тот, наверно, кому плохо платят и сам он не может делать расширения. И почему он оказался в основе процесса?
Хорошо он проверил или плохо, все равно надо потом быстро доставить клиенту обновленный код.
Значит ситуация «деньги платили уже, но открыли и снова не работает» у клиента обычная.
Ведь они параллельно стажеру работают. Они ведь ставят обновления типовой по мере выхода.
После обновления они должны включить мозги и вспомнить что 1сная конфигурация — это одно, а расширение брали в другом месте. Какой-то подписной сервис надо мутить. Да еще и очень срочный. Деньги брать по подписке или стажер бесплатно работает?
Мутить какую-то муть. Обычные 1сные дела.
Я в начале года накачал несколько расширений для разных конфигураций, сейчас открыл — ни одно не заработало. Новых версий там, где их брал — нет. Надо разбираться, но проще понять их идею и выкинуть.
Может все таки, как и прежде, пускать через себя конфигурацию и выдавать ее каждый раз рабочей? Та же работа по поддержанию согласованности доработки и основной, только за один шаг и без стажера.
(5) в любом случае, поддерживать доработки все равно потребует затрат, я только предложил способ как сэкономить на поддержке, создав такое расширение, которое будет минимально зависеть от изменений расширяемой конфигурации
либо вы дорабатываете конфигурацию традиционным способом со всеми вытекающими,
либо вы делаете расширение
в идеале, расширение вам придется дорабатывать только тогда, когда обновленная конфигурация вступает в конфликт с прикладной логикой расширения, в этом случае вам точно придется дорабатывать расширения для совместимости, но все тоже самое вам придется делать в любом случае (либо вовсе отказываться от обновлений конфигурации)
что интересно, если расширение будет заимствовать только объекты, использованные в прикладной логике расширения, то перестанет оно работать только при критических для него изменениях, причем работать перестанет на уровне запуска 1С:Предприятия, что упрощает процесс мониторинга критичеких изменений, который можно переложить на неопытного специалиста (а еще лучше на скрипт), а если он обнаружит — включаться в процесс самому
(6)
Плохо то, что клиент получит ситуацию отказа параллельно и независимо от качества и быстроты работы с актуальностью расширений. Прямые претензии пойдут сразу к вам. Отвечать можно только «подождите — сейчас сделаем».
Вы с клиентом получаете обновления одновременно.
Например, клиент лоялен и заинтересован в доработке, что ему сделать, чтобы не получать отказ?
Отменить обновления и ждать актуального, проверенного расширения от вас.
Отменить обновления, чтобы сохранять возможность обновлений. Как-то так что ли?
Головная сейчас ERP, из нее все остальные основные нарезаются. Недавно сменила вторую цифру, имея уже целую простынь предыдущих релизов. По идее «стажером» должен быть скрипт, а не человек и он все их должен перелопатить. Ацкая жесть. И какая то левая работа по поводу уже полученных денег.
По моему цель механизма расширений — это быстрое отключение доработок в пользовательском режиме запуска. Вендор свое доставит, а вы сами как-нибудь разбирайтесь там. Ну так можно с самого начала и разбираться самим.
(6)
В случае расширения гарантирована остановка эксплуатации и конфликт на вашем уровне заказчик — исполнитель. 90% доработок — наследующие и расширяющие функционал.
Процентов на 10 — да мы независимы.
Кроме работы просто по адаптации к текущей версии, нарубилась работа с адаптированностью всей системы к будущим релизам. Да еще и в заведомо авральном порядке.
Не совсем понятно, где и чей тут профит?
(8)
функционал после изменения конфигурации в любом случае перестанет работать.
это экономия по следующим причинам:
1. если расширение не работает, то оно просто отключается, клиент теряет только функционал расширения без утраты возможностей конфигурации (если 8.3.11 и добавлены реквизиты в объекты — будут дополнительные проблемы, связанные с записью объектов)
2. тот факт, что расширение не работает, понятен сразу на этапе запуска программы после обновления: оно сразу отключается с выводом на экран сообщения об ошибке, не надо сравнивать при каждом обновлении: пока работает — все хорошо, это можно сделать на демо базе
3. в большинстве случаев (когда обновление не касается заимствованных объектов) клиент просто обновляет конфигурацию стандартными средствами, либо это делает стажер
(0) Возможен еще один подход с расширениями. В проде не пробовал, но эксперементировал — он работает..
Суть: не надо в одно расширение добавлять все доработки. Одна доработка — одно расширение. В итоге — на конфигурации будут висеть много расширений. Каждое из них — это одна цельная задача доработки..
В этом случае при конфликтах «поле» работы более узкое и понять, что не так — гораздо легче.
PS при этом нужно стараться разрабатывать так, чтоб каждое расширение было независимо от других. Но иногда это проблематично — разные расширения могут обращаться к одним и тем же реквизитам и менять их типы/наборы типов.
Тогда можно поступить так — самое «глубокое» расширение делаем базой для всех — и храним в нём ТОЛЬКО изменения ТИПОВ метаданных — никаких форм, бизнеслогики и разного кода.. уже поверх него — «накладываем» наши доработки форм/кода/событий в разрезе отдельных доработок — т.е. у нас будет максимум одна зависимость.
PS2 Загрузка конфигурации при увеличении количества расширений — будет всё дольше и дольше.. насколько это критично — нужно ставить эксперименты и смотреть.
(9)
1. если расширение не работает, то оно просто отключается, клиент теряет только функционал
Это НЕ экономия. Это новые затраты на восстановление уже полученного результата. Да еще и по причине активности третьего участника процесса.
Заход чисто наш, 1сный: «Наше расширение будет у вас работать всегда. Или очень долго. Ну или завтра перестанет. Оплачивайте в кассу. Это экономия.»
(10)
А вот это уже хорошо. Я не допер сам. Отвалилась одна задача, а не все сразу.
Но вроде иерархию построить нельзя. Разве бывают расширения расширений?
(11) лучше все-равно ничего нет.
Либо отказывайтесь от доработок, либо отказывайтесь от обновлений.
Здесь описывается способ снизить затраты на поддержку, когда доработка клиенту нужна и когда обновления ему тоже нужны.
(10)это логично, я так делал
(13)
Либо обновляешь себя с доработками в хранилище и обновляются они сами на автомате скриптом по готовности из него по инету.
Никаких затрат покупателю, кроме резонной поддержки доработки, никаких внезапных слетов, никаких буферных конфигураций и никаких стажеров в деле. И даже стажер вообщем-то может сравнить — объединить в один шаг.
Такие дела с затратами.
(15)предлагаю посвятить этому отдельную публикацию, мне тоже будет интересно изучить способ бесплатного (или почти бесплатного) обновления измененных конфигураций
(10) А Вы вообще читали как работают расширения? Как вызываются перед, После, Вместо , когда в конфигурации не одно такое расширение. Вы вообще понимаете, что предлагаете?!
Оно конечно работать будет но это чушь одним словом. Тоесть поступила задача в заказе покупателя после того как внесли клиента проверить долг и вывести предупреждение — по вашей логике это расширение 1
Через два дня поступает еще задача, после проверки долга надо чтобы , когда долг был больше тысячи блокировать продажи (расширение 2)
и т.д. это чушь
У меня аж волосы дыбом… ФАК, а как среди тысячи расширений и форм Заказ покупателя искать, что в них . МАТЬ моя женщина!
А потом приходишь после такого, и рыдать хочется…
Кто-то не вкурил в тему расширений вообще.
В 8.3.10 вы например выбираете уже конкретно, что это за раширение — дополнение, изменение и т.д.
Кроме этого, в 8.3.11 — вы можете расширять реквизиты.
Ну и на последок — есть такоя штука — проверка совместимости, вот ее надо юзать.
А те недогалочки — снимать, и тогда будет все хорошо.
(19)
с помощью этого инструмента описанную проблему не решить
с помощью этого инструмента описанную проблему не решить, кроме того, официально этот релиз еще не вышел, на проектах у клиентов его использовать пока нельзя
1. Не снимает проблемы переименования/удаления метаданных
2. щелкать по всем галочкам — тоже трудоемкий процесс
(17)
(17)
Речь идет о расширениях, которые не пересекаются по решаемым задачам. поэтому проблемы нет.
(17)
В этом случае новое расширение не добавляется, изменения вносятся в ранее созданное
(16)
Статейку возможно надо написать, хотя изучать там особо нечего. Все это вендор должен по идее писать, рассказывать.
Им или некогда с нами возиться или нет желания.
При обновлении через хранилище целевой рабочей базы передается не только рабочая версия доработки, но и конфигурация поставщика.
(19)
Она как раз и проверит заимствованное ранее с текущей основной?
Жаль только, что проверка всегда позже появления факта несовместимости.
(22) если Вы работаете через хранилище, это не избавляет Вас от сравнения и объединения с обновленной конфигурацией поставщика.
все тоже самое получается, плюс работа с объектами хранилища: захватить/поместить/получить
Таким способом вы ни секунды рабочего времени не экономите даже в теории
(20)
Похоже уже нет разницы, где релиз, а где тестовый или ознакомление. Оно наверно по дате переходит из столбика в столбик.
На 10-м релизе недавно вылетали внешние обработки в толстом и индексы. Упали — отжались. Теперь будет две платформы.
А сколько косяков с расширениями, приводящих к падениям? Последний раз, когда делал расширение словил подряд раза 3-4 и чего-то слегка охладел.
(21)
Это бы хорошо, конечно. Но Номенклатура, КонтрагентыПартнеры, ТоварыНаСкладах будут во многих расширениях сразу.
А расширения будут делаться в разное время, в течении которого могут даже эти справочники и регистры измениться.
(25)
Вот как вы экономите:
«В результате, я нашел способ: создавать и разрабатывать расширение на полупустой конфигурации, которая содержит минимум объектов из типовых ПП, для которых, собственно, и делается расширение.»
Вы делаете буфер, который сравниваете с измененной. Потом, если изменился буфер, переделываете расширение.
Плюс какой-то стажер проверяет что оно работает с вышедшей типовой.
Плюс — всегда, когда меняются объекты заимствованные в расширение, для начала возникает ошибка у заказчика.
Расскажите еще что-нибудь про экономию.
(28) буфер я создаю, что бы в нем создать форму с минимальным количеством нужных элементов не заимствуя ничего лишнего,
экономия времени получается, когда клиент получает автоматическое обновление (либо легко склеиваемое обновление, если будут только добавлены новые метаданные в его конфигурации*) и функционал расширения, которое не будет ломаться с обновлениями (либо будет, но редко)
*а начиная с версии платформы 8.3.11 можно еще больше доработок вынести в расширение и еще сильнее сэкономить на поддержке
для того и создается буферная конфигурация, что бы минимизировать количество заимствованных объектов, что бы расширение с меньшей вероятностью становилось неработоспособным при обновлениях конфигурации
+ преимущество расширения: если оно не работает на новой конфигурации — это сразу видно при запуске программы, не надо много времени тратить на тестирование совместимости
Интересно. С расширениями не работал вообще, но плюсанул. Лишние зависимости — это всегда зло. Для заказных расширений профит очевиден и перекрывает доп. неудобства, ИМХО.
(29)
Расскажите когда это стало преимуществом?
Клиент может оперативно отключать работу, которую уже оплатил? Клиент должен знать наперед, что у него что-то может отвалиться и относиться к этому спокойно?
Наверно надо не делать через расширения ничего, что может приводить к отказам в долгосрочной перспективе. А что тогда делать?
Может быть, если клиент упорно не хочет снимать конфигурацию с замка, то можно работать только так. Ознакомить с прейскурантом для упертых и вперед.
Вот это вот «упорно не хочет», экономия и деньги — вообще в разных местах.
(31)
Это простота тестирования: не надо проходить все кейсы использования функционала, просто запускаешь (на пустой, тестовой или демо-базе) обновленную базу и на запуске платформа выдает ошибки несовместимости.
То есть, что бы понять, что что-то в расширении перестало работать, достаточно только 1 раз запустить базу, можно использовать демо-базу.
Это лучше, что искать ошибку другими способами.
Можно, если расширение тиражируется, заранее держать под рукой демо-базу ПП, которую обновлять по мере выхода обновлений (на
«1C:Обновление программ» публикуются релизы для тестирования), в случае утраты совместимости — делать новую версию расширения.
Если у клиента подключено расширение либо иным способом в его программу внесены доработки, то обязанность внедренца его уведомить о том, что при обновлении часть функционала доработок может утратить работоспособность. Из-за этого порой вообще отказываются от обновлений.
Если клиент хочет внести изменения в конфигурацию и получать её обновления, ему в любом случае придется заплатить. Я просто ищу способ уменьшить эту сумму, что бы сделать нашу работу более эффективной и выгодной.
(31) Не понял. Вы хотите сказать, что клиенту выгоднее «снять конфигурацию с замка» и оплачивать работу специалиста по КАЖДОМУ обновлению? Вы это серьезно?
Конечно, клиента нужно предупреждать о преимуществах и недостатках продукта, за который он платит. Это называется добросовестной сделкой.
(33)
Конечно, клиента нужно предупреждать о преимуществах и недостатках продукта, за который он платит. Это называется добросовестной сделкой.
Вы это просто так спрашиваете?
К примеру, у вас ERP 2.2 на автообновлении. 1С выложила 2.4. Клиент автоматом поставил ее. Расширение вылетело. Дальше что?Будете рассуждать о «достоинствах и недостатках»?
У них уже все вылетело и они даже не знают можно ли продолжить работать уже без расширения.
Я присылаю «новое в версии» им сначала, а вы будете разгребать создавшуюся ситуацию потом. Да может быть и целой серией исправлений, когда меняется что-то через ряд исправительных релизов типовой.
Какая вообще разница серьезно я или не серьезно. Сами попробуйте мозгом подумать — это ваша работа.
(32)
Расширения — это очень хорошо. Я не против них. Есть клиенты которые видят в 1сном замке гарантию стабильности.
Только платят они в итоге больше.
Обожаю статьи, где комментарии значительно больше инфы дают 🙂 За статью спасибо, не думал о таком способе создания расширений. Но пока что-то страшновато их использовать, видимо просто информации по ним пока маловато.
(17) События До и После отрабатывают по очереди — даже если расширите один и тот же объект. Так что если бизнеслогика расширений работает независимо — то проблем не будет.. но это не значит, что голову нужно отключать 🙂
С событием Вместо — не знаю как будет себя вести.. оно появилось позже остальных и с ним экспериментов не ставил. Надо посмотреть, как поведут себя расширения в этом случае. Думаю, что проблему решить и тут можно, но сам механизм расширений костыльный — так что и решение будет не лучше..
А что бы ориентироваться среди множества расширений — просто кодируйте их и ведите журнал разработки, например, в привязке к задачам или требованиям проекта. При большом проекте всё равно от документирования не уйти.
А так — подумайте — расширения же придумывались изначально как способ добавления разной функциональности от разных поставщиков для облака фреш — т.е. сама задумка была у 1С такая, что должны работать несколько расширений вместе — и они вполне могут перекрываться по объектам.. автор как раз показал, как реквизиты добавлять правильно — так можно разными расширениями разное добавить. А чтоб не перекрываться — нужны уникальные неймспейсы.. в 1С это выродилось в использование префиксов.
Короче, все хорошо в меру и каждому инструменту — своё место;)
==
PS Но на самом деле — я для себя решил, что нет ничего лучше выгрузки в git и работе с кодом (слияния/объединения) через него. Практика пока показывает, что это наиболее оптимальный путь для управления кодом. Расширения же, на мой взгляд, менее удобный и менее гибкий механизм доработки, применимый к небольшим и узким задачкам.. все ИМХО.
Расширения, безусловно помогли в разработке. В основном пока в качестве редактора форм, т.к. большинство конф еще в режиме совместимости 8.3.8. Личная практика использования показала, что Подписки на события, свои модули, свои объекты плюс доп свойства — оптимальный путь решения задач для поддержки совместимости. Но эьто не отметяет того, что за всем этим зоопарком надо следить, иначе Совместимые конфы не поддерживались бы разрабами от релиза к релизу, а как мы видим, такого не происходит.
(34) Думать мозгом — святая обязанность homo sapiens в целом.
Выбор клиента и только клиента — платить больше денег за уменьшение своих компетенций и рисков или платить меньше денег, беря на себя определенные риски и компетенции. Любое обновление может быть калечащим — для этого не обязательно расширения иметь.
Для того, чтобы накатить авто-обновление на копию рабочей базы — достаточно эникейщика или обученной обезьяны. Не привлекать в большинстве случаев для обновлений высокооплачиваемого специалиста — прямой профит. При соблюдении минимальной техники безопасности — никаких рисков.
«Сами попробуйте мозгом подумать» (с)
Если клиент согласен полностью переложить на вас ответственность за качественные обновления за свои деньги — это его выбор. Но далеко не единственный и не такой однозначный, как вы тут пытаетесь нарисовать.
Расширения в ЛЮБОМ случае упрощают и облегчают процесс обновлений. Неважно, кто его осуществляет. Клиент своими силами или сторонние специалисты.
Кто это доктор? Ваши коллеги по франшизе? «Обезьяны обученные» 🙂 Это те, что стажеры у автора?
Какой-то обязательный воображаемый и дрянной компонент процесса.
Заметно, что сами вы сразу поступили в «программисты 1С» прямо из роддома, поэтому напишите еще, куда и что надо перекладывать, а также как надо «уменьшать компетенции»
(40) Писать вам что-либо еще не вижу смысла. По не очень лестным для вас причинам.
Спасибо за статью, очень познавательно.
Как отмечали выше, желание использовать расширения после узнанного пропадает
таки да, если фран со 100500 клиентов, то может и можно, если фикси и несколько баз с кучей доработок, то вопрос использования расширений вообще не стоит.
(43)
таки да , если франч продает расширения которые не зависят от метаданных основной конфигурации , только много ли таких?
(4) Попробуйте удалять не элементы формы, а реквизиты объекта
(45) кроме реквизитов самого объекта много других объектов подтягивается, в конце концов получается очень много всего надо удалить (другие справочники, картинки, функциональные опции, константы, много всего…),
смысл понятен, но я таким способом не пробовал делать, не думаю, что это хорошая альтернатива
Работает!
Не могу воспроизвести повторно аналогичный фокус. Без использования другой конфигурации создал расширение формы без элементов формы. Реквизит формы Объект пустой, тип не задан. В форме переопределены несколько функций.
Работает нормально. Вероятно есть какая-то недокументированная возможность. 😉
Фирма 1С сообщает, что в версии 8.3.14 данный «Ход конем» будет не нужен.
Будет изменен механизм заимствования форм в расширение.